Block based design methodology

ABSTRACT

A method and apparatus for designing a circuit system, including selecting a plurality of pre-designed circuit blocks to be used to design the circuit system, collecting data reflecting the experience of the designer regarding the pre-designed circuit blocks, the designer&#39;s experience being adaptable to a processing method, accepting or rejecting a design of the circuit system in a manner based on the designer&#39;s experience data and acceptable degree of risk, upon acceptance, forming block specifications containing criteria and modified constraints for each of the circuit blocks, upon acceptance, forming block specifications for deploying the circuit blocks on a floor plan of a chip, as a system on a chip, in compliance with the criteria and modified constraints, and substantially without changing the selected circuit block and the processing method.

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application depends for priority upon commonly assigned U.S.Provisional Patent Application No. 60/102,566, entitled BLOCK-BASEDDESIGN METHODOLOGY, filed Sep. 30, 1998, which is incorporated herein inits entirety by reference.

FIELD OF THE INVENTION

[0002] The present invention relates generally to integrated circuit(“IC”) device design, and more specifically to the design of systemsre-using pre-designed circuit blocks.

BACKGROUND OF THE INVENTION

[0003] In recent years, constant innovation in silicon processtechnology has drastically reduced the price and increased theperformance and functionality of integrated circuit devices, thusstimulating the development of the electronics manufacturing andinformation processing industries. In turn, these fast growingindustries impose increasing demands on the integrated circuit designsystem developers for still faster and cheaper devices. As a result, thedesign industry is now undergoing drastic changes, including:

[0004] (1) Chip designs are getting larger and more complex. Forexample, in 1997, a typical integrated circuit contained from 100-500Kgates. In 1998, the typical device contained one to two million gates.Technology in 1999 has shown the continuation of this trend with devicesof four to six million gates being built.

[0005] (2) Chip designs are becoming more application-specific. In theearly days of IC design, device manufactures would produce various“off-the-shelf” chips, which end users would design into theirelectronic products. Currently, electronic product manufactures moreoften order custom chip designs to perform specific functions.

[0006] (3) Electronic product development is now primarily driven byconsumer demand, which has shortened product life cycles and, thereforeshortened allowed design time and resources. For example, in 1997, theaverage design cycle was between 12-18 months. In 1998, that averagetime decreased to 10-12 months and in 1999 the industry is pushingtowards 8-10 month design-cycle times.

[0007] (4) Design time constraints require parallel design effort.Formerly, critical design decisions for upstream system components couldwait until downstream system component designs were verified. Designmanagers no longer have the luxury of sequentially performing designtasks. Several system components may have to be developed concurrently.Thus, design managers are required to make crucial predictions before atleast some system component designs are complete.

[0008] To address these demands, electronic system design is now movingto a methodology known in the art as Block Based Design (“BBD”), inwhich a system is designed by integrating a plurality of existingcomponent design blocks (also referred to in the art as “intellectualproperty blocks” or “IP blocks”). These pre-designed blocks may beobtained from internal design teams or licensed from other designcompanies, and may be supported by fundamentally different designstructures and environments. Moreover, pre-designed blocks may bedeveloped to meet different design requirements and constraints.

[0009] Another challenge faced by designers using BBD is the front-end(project acceptance) delays and risk brought about by uncertainty indetermining system design feasibility. Current ASIC(application-specific integrated circuit) designs are primarilypresented at the RTL (register transfer level) stage, and some evenearlier, at specification level, to designers by customers. Thesedesigns are then partitioned in a manner based upon the limitations ofavailable synthesis technology, according to the area, performance, andpower tradeoffs required to provide cost-effective implementation. Inthis manner, the designer accepts a system specification as input andultimately provides a netlist-level design for physical implementation(including design place, route, and verification). If designspecifications are within the capabilities of the intended or availableprocessing technology, including clocking, power, and sizespecifications, the available design methodology is reasonablypredictable and works well with available circuit design tools.

[0010] However, the RTL-level design and the system-level designactivities are typically uncoupled or loosely coupled, meaning there isno coherent link from the system-level functional definition to the ASIC(RTL) level. The RTL-level design is developed based upon a paper ASICspecification and verified by a newly formed test suit created aroundthe ASIC interface. Thus, available design and implementationmethodologies for ASIC design present a number of problems, which hamperefficient block integration.

[0011] First, current methodologies do not provide a top-down approachto comprehensively evaluate and ensure compatibility to integrate aplurality of design blocks provided by multiple sources having differingdesign considerations, while providing hierarchical verification andshort assembly time within tight time-to-market constraints.

[0012] Also, existing methodologies for ASIC design do not providescalability. A significant number of existing methodologies are focusedaround a flat design. This approach has led to significant problems inthe length of time required to assemble the top-level design for asystem having more than one million gates.

[0013] In addition, existing ASIC design methodologies are not suitablefor reuse of pre-designed circuit blocks. Available schemes do notprovide guidelines to solve the timing, clock, bus, power, blockarrangement, verification, and testing problems associated withintegrating circuit design blocks within specific device architectures.Thus, without a comprehensive approach to block reuse, existingmethodologies bring about an ad-hoc and unpredictable design approach,reduce design realization feasibility, increase cost and time todelivery, and often trigger performance-reducing modifications to thepre-designed circuit blocks themselves in order to fit them into thedesigned system. Furthermore, existing methodologies do not provideperformance trade-off analysis and feedback of critical designparameters, such as clock frequency, and area versus risk ofsuccessfully and predictably completing chip designs andimplementations.

[0014] There is, therefore, a need for a methodology that can satisfythe evolving environment and address the shortcomings of the availableart.

[0015] There is also a need for a suitable methodology for using andreusing pre-designed circuit blocks from multiple sources in a circuitdesign.

[0016] Combining IP blocks also brings about the need for “glue” logic,the logic that allows the blocks to work together on a single device.Glue logic is the logic primarily responsible for interconnecting designblocks, and normally resides between the blocks, dispersed throughoutthe design. Glue logic elements can be added to a design during variousstages of chip planning, or can reside at the outermost boundary of eachblock within a design to act as an interconnect mechanism for the hostblock. Regardless of its source, glue logic must be optimally placedwithin the design to minimize wire congestion and timing complicationswhich arise from placement of glue logic between blocks, introducingdelays which may not have been contemplated by the original blockdesigner.

[0017] There is therefore a need in the art to which the presentinvention pertains for an improved method of placing and distributingglue logic in a block based design.

[0018] There is also a need for a glue logic distribution mechanism thattakes into account the functional affinity of various glue logicelements, and groups them into new design blocks.

[0019] There is also a need in the relevant art for a glue logicdistribution mechanism that returns an optimized amount of glue logic toexisting designs.

[0020] In addition, existing ASIC design methodologies are not suitablefor reuse of pre-designed circuit blocks. Available schemes do notprovide guidelines to solve the timing, clock, bus, power, blockarrangement, verification, and testing problems associated withintegrating circuit design blocks within specific device architectures.Since the circuit blocks are from multiple inconsistent sources, thechallenge is how to integrate these circuit blocks into a circuit systemin a fashion suitable to block-based design.

[0021] Therefore, there is a need for a method and apparatus suitable tointer-connect the circuit blocks from multiple inconsistent sources in afashion suitable to block-based design.

[0022] There is another need for a method and apparatus to provideinterfaces for converting the circuit blocks having different interfacesinto the ones having standardized interfaces.

[0023] Of course, all ICs, even those containing an entire system on asingle chip, must pass a series of tests to verify that the chip meetsperformance requirements and that there are no hidden manufacturingdefects. If a manufacturing defect is missed, the faulty chip may not bediscovered until after the assembly process or, worse yet, in the field.The cost of such “test escapes” in terms of their effect on customersatisfaction can be devastating to a product line.

[0024] Generally, there are three types of tests for detecting defects:DC parametric tests, AC parametric tests, and functional (“PLL”) tests.In DC parametric tests, the inputs, outputs, input-to-outputtransmission, total current, and power consumption of the chip aremeasured. In AC parametric tests, the rising and falling times of theinput and output signals, delay time in propagation between input andoutput terminals, minimum clock pulse width, and operation frequency ofthe chip are measured. In functional tests, the chip is tested to see ifit functions as designed under prescribed operating conditions.Typically, applying a test pattern to an input terminal (“test vectors”)and comparing an output pattern detected at an output terminal with anexpected pattern carries out a functional test.

[0025] Before the advent of Design for Test (“DFT”) methodologies,designers created and assembled a chip, then passed the completed designto test designers. The test designers then added package-level testlogic, and sent the chip to the manufacturer (the “fab”). The fabtesters then probed the chip and ran a board test protocol including theabove-described tests on the package-level logic. The available ScanDesign methodology is a simple example of a highly effective and widelyused method for applying a “single” test method to the entire chip withpredictable and consistent test result. Other ad hoc methods may be usedto handle nonscannable design styles.

[0026] Today, logic previously contained in a whole chip is now used asa single virtual component (VC) or design block to be included in alarger chip. Thus, tests can no longer be designed after circuit designis complete. Designers must plan how to test each design block, as wellas the whole packaged chip, throughout the design process. The designprocess must therefore ensure testability by applying one or more testmethods as appropriate.

[0027] The benefits of DFT are well known. DFT logic and test vectorverification functions allow shorter, production-ready tests early in aproduction cycle. Also, DFT scan paths provide access to chip and systemstates that are otherwise unavailable. A good DFT plan thereby shortenstime-to-market and reduces testing cost by easing the front-end designprocess and the development of manufacturing tests.

[0028] There are therefore four needs presented by the available art.First, a new DFT for BBD must be able to make effective use of thepre-designed test data among other dissimilar test methods, to sharelimited test access, and to meet the overall SOC level test objectives.

[0029] Second, it must face the emerging difficulties of new defecttypes and new defect levels due to technology scaling, the newcomplexities of mixed-signal and mixed technology design, and theincreasing I/O count and new packaging techniques.

[0030] Third, it must face the difficulties of integrating IP blocks,which inherently lack a unified structural test model. SOC level testaccess and fault isolation are needed, and the demand for low powerdesign techniques (i.e., latch-based, gated clock, derived clock,pipelines, and low threshold voltage) which are largely unsupported bythe currently available DFT methodologies must be addressed.

[0031] And the new DFT methodology must overcome the time to marketpressure with a coherent and consistent test integration model even whenfaced with limited or inadequate test information.

[0032] The available art requires structural information (i.e., faultmodels and test models) so that the test data can be partially or fullygenerated and verified for a set of faults. For example, the Scan DesignMethodology is only applicable to synchronous design and detects onlysingle stuck-at-fault models. Moreover, other DFT solutions arescan-based, thus making it rather difficult for sharing and verifyingthe hard IP test model, which does not contain structural information.

[0033] The available art also requires a non-linear computation modelthat cannot sustain the current gate count explosion, even if sharingand verifying were possible (i.e., soft IP models). However, soft IPsare not necessarily scannable or mergeable, sometimes resulting inunpredictable and unmanageable test development.

[0034] Turning finally to design verification, a challenge presented bythe use of multiple pre-designed blocks in SOC design is the need for areliable and efficient functional verification method. In the availableart, test suites are used to verify a multi-block design. Each test inthe suite is used to test each of the blocks before they are integrated.Then, after integration of the blocks, significant effort is required toadjust the test suite to enable functional verification at the systemlevel. The process of testing and debugging may need to be repeated fora number of iterations before a final, full system verification can beconfidently provided.

[0035] One available approach to this problem is the substitution ofimplementation modules for their corresponding behavioral models,thereby allowing chip level simulation and testing in a mixed modesituation. While this approach can offer desirable results if performedeffectively, and can be less costly than the iterative block-basedsimulations described above, this approach is still quite expensive andslow, since the entire chip must be simulated to obtain reliablefunctional verification.

[0036] An especially acute challenge is presented in multi-block designsby the need to functionally verify bus structures. In the available art,bus verification is achieved in either of two ways. The bus may bedebugged and verified as an integral part of the overall chip, or it maybe verified using bus functional models for the pre-defined blocks,taking into account the detailed implementation provided by newlyauthored blocks. However, integral bus verification can be slow andcostly. The entire chip must be used to verify the bus design, andintegral bus verification can only be executed late in the design cycle,when debugging is difficult and time consuming due to the level ofdetail and the potential for finding no bus-related bugs. The busfunctional model approach eases some of these problems, but requiresimplementation detail for the newly authored blocks. Moreover, the busfunctional models may be error prone themselves and may be availableonly as “black boxes”, making signal tracing and debug difficult orimpossible.

SUMMARY OF THE INVENTION

[0037] To addresses the shortcomings of the available art, the presentinvention provides a method and apparatus for designing a circuitsystem, the method, comprising the steps of:

[0038] (a) selecting a plurality of pre-designed circuit blocks to beused to design the circuit system;

[0039] (b) collecting data reflecting the experience of the designerregarding the pre-designed circuit blocks, the designer's experiencebeing adaptable to a processing method;

[0040] (c) accepting or rejecting a design of the circuit system in amanner based on the designer's experience data and acceptable degree ofrisk;

[0041] (d) upon acceptance, forming block specifications containingcriteria and modified constraints for each of the circuit blocks (FEA);

[0042] (e) upon acceptance, forming block specifications for deployingthe circuit blocks on a floor plan of a chip, in compliance with thecriteria and modified constraints without changing the selected circuitblock and the processing method.

BRIEF DESCRIPTION OF THE DRAWINGS

[0043]FIG. 1 is a flowchart illustrating a design process based on theblock-based design methodology, in accordance with the presentinvention;

[0044]FIG. 2 is a flowchart illustrating the steps of front-end access,in accordance with the present invention;

[0045]FIG. 3 illustrates a clock-planing module, in accordance with thepresent invention;

[0046]FIG. 4 illustrates a bus identification and planing module, inaccordance with the present invention;

[0047]FIG. 5 illustrates a power-planning module, in accordance with thepresent invention;

[0048]FIG. 6 illustrates the I/O and analog/mixed-signal requirements,in accordance with the present invention;

[0049]FIG. 7 illustrates a test-planning module, in accordance with thepresent invention;

[0050]FIG. 8 illustrates a timing and floor-planning module, inaccordance with the present invention;

[0051]FIG. 9 shows meta flow of a block design, in accordance with thepresent invention;

[0052]FIG. 10 illustrates data flow of a chip assembly, in accordancewith the present invention;

[0053]FIG. 11 illustrates task flow of a chip assembly, in accordancewith the present invention; and

[0054]FIGS. 12, 13, 14, and 15 illustrate functional verification flowin accordance with the present invention.

[0055]FIG. 16 illustrates a methodology to assess feasibility of acircuit design using a plurality of pre-designed circuit blocks, inaccordance with the present invention.

[0056]FIG. 17 illustrates a feasibility assessment result using themethodology shown in FIG. 2, in accordance with the present invention.

[0057]FIG. 18 shows a methodology to assess feasibility of a circuitdesign using a plurality of pre-designed circuit blocks, in accordancewith the present invention.

[0058]FIG. 19 illustrates a feasibility assessment result using themethodology shown in FIG. 18, in accordance with the present invention.

[0059]FIG. 20 shows an front-end acceptance (“FEA”) process, inaccordance with the present invention.

[0060]FIG. 21 illustrates a refinement process, in accordance with thepresent invention.

[0061]FIG. 22 shows an exemplary estimate correctness curve, inaccordance with the present invention.

[0062]FIG. 23 shows a process of validating an FEA, in accordance thepresent invention.

[0063]FIG. 24 shows a refined estimate correctness curve using an FEAdesign-property refinement process, in accordance with the presentinvention.

[0064]FIG. 25 shows an FEA data-extraction process, in accordance withthe present invention.

[0065]FIG. 26 illustrates a process of identifying the need forblock-estimate refinement, in accordance with the present invention.

[0066]FIG. 27 shows an FEA assessment-axes metric, in accordance withthe present invention.

[0067]FIG. 28 shows a classification collapse curve, in accordance withthe present invention.

[0068]FIG. 29 shows a plurality of design blocks in a circuit design,wherein glue logic interferes with optimal design block placement.

[0069]FIG. 30 illustrates a first type of glue logic distribution, inaccordance with the present invention.

[0070]FIG. 31 illustrates second and third types of glue logicdistribution, in accordance with the present invention.

[0071]FIG. 32 shows a collaring process of embedding a circuit blockinto a collar, in accordance with the present invention.

[0072]FIG. 33 illustrates creating a complete set of abstracts for ablock, to be used in a design in accordance with the present invention;

[0073]FIG. 34 is a flowchart illustrating the collaring process, inaccordance with the present invention.

[0074]FIG. 35 shows a collar having two layers, in accordance with thepresent invention.

[0075]FIG. 36 illustrates the logic view between a collar and a circuitblock, in accordance with the present invention;

[0076]FIG. 37 illustrates the physical view between a collar and acircuit block, in accordance with the present invention.

[0077]FIG. 38 shows a system design without using the collaring processof the present invention.

[0078]FIG. 39 shows a system design using the collaring process of thepresent invention.

[0079]FIG. 40 shows a computer system for performing the steps in thecollaring process of FIG. 34, in accordance with the present invention.

[0080]FIG. 41 illustrates a series of steps comprising the busidentification and planning scheme of the present invention.

[0081]FIG. 42 illustrates the internal structure of an interconnectionsection of a behavioral model constructed according to method of thepresent invention.

[0082] FIGS. 43-47 and 49-56 are tables illustrating improved delaytimes through bus modifications implemented using the system and methodof the present invention.

[0083]FIG. 48 illustrates a bus bridge used in the method and system ofthe present invention.

[0084]FIG. 57 illustrates a bus bridge used in the method and system ofthe present invention.

[0085]FIG. 58 illustrates a bus bridge including a FIFO used in themethod and system of the present invention.

[0086]FIG. 59 is a table illustrating bus utilization and latencycharacteristics for a variety of bus types.

[0087]FIG. 60 illustrates an Exemplary Consistency Check truth table

[0088]FIG. 61 illustrates the top-level hierarchy of a chip from the DFTperspective using the method of the present invention.

[0089]FIG. 62 illustrates a design made up of functional blocks andsocket access ports (“SAPs”).

[0090]FIG. 63 is a table illustrating appropriate test methods for avariety of design architectures.

[0091]FIG. 64 is a flowchart illustrating the top-level architecturespecification procedure for the method and system of the presentinvention.

[0092]FIG. 65 illustrates a socketization procedure of the method andsystem of the present invention.

[0093]FIG. 66 illustrates a block level test development procedure ofthe method and system of the present invention.

[0094]FIG. 67 illustrates a chip level test development procedure of themethod and system of the present invention.

[0095]FIG. 68 illustrates a test flow from planning to chip assemblyaccording to the method and system of the present invention.

[0096]FIG. 69 illustrates a designer's view of the front-end acceptanceverification tools of the present invention.

[0097]FIG. 70 illustrates a designer's view of moving from chip planningto block design.

[0098]FIG. 71 illustrates a designer's view of the evolving bus blockmodel and test bench generation of the method and system of the presentinvention.

[0099]FIG. 72 illustrates a designer's view of a block test bench and achip test bench.

[0100]FIG. 73 is a designer's view of block and chip logicalverification models.

DETAILED DESCRIPTION PREFERRED AND ALTERNATIVE EMBODIMENTS

[0101] To overcome the shortcomings of the available art, the presentinvention discloses a novel methodology and implementation forblock-based design (“BBD”).

[0102] Referring to FIG. 1, a flowchart 100 illustrating a designprocess based on the block-based design (BBD) methodology in accordancewith the present invention is shown. As shown in FIG. 1, the designprocess includes front-end acceptance design stage 102, chip planningdesign stage 104, block design stage 106, chip assembly design stage108, and verification design stage 110.

[0103] Front-end acceptance design stage 102 enables a system integrator(chip designer) to evaluate the feasibility of a prospective designproject. At front-end acceptance design stage 102, the designer receivesa specification from a customer including functional and otherrequirements (such as delivery time and budget) for designing an ASIC.The customer may also provide some pre-designed circuit blocks and testbenches for these circuit blocks. Along with the customer suppliedblocks, the designer utilizing front end acceptance design stage 102 mayaccept, as input, circuit blocks from different sources, some of whichmay be supplied by a third party, some of which may be legacy circuitblocks, and some of which may be newly authored. These selected circuitblocks can be in a soft, firm, or hard design state. (Note that: softstate is at RTL level; hard is at GDSII level; and firm is between softand hard, such as at gate level or netlist level). Front-end acceptancedesign stage 102 then collects the designer's available experiences,including field of use data, estimation data through behaviorsimulation, and/or partial implementation data. The process of front-endacceptance design stage 102 then provides an assessment to help thedesigner decide whether to accept the design project based on the designproperty parameters, including the customer's requirements, thedesigner's available experience, and the designer's acceptable degree ofrisk. Furthermore, based on the functional specification, the result offront-end acceptance design stage 102 dictates the final set ofpre-designed circuit blocks to be used in the circuit design.

[0104] Front-end acceptance design stage 102 provides for three phasesof assessment: coarse-grained assessment, medium-grained assessment, andfine-grained assessment. If an assessment at one phase is notsatisfactory, front-end acceptance design stage 102 enables refinementof design property parameters and makes a further assessment at the nextphase.

[0105] If the proposed design project is found acceptable, front-endacceptance design stage 102 provides comprehensive steps to ensure thatproblems in the design ahead are detected early, and to ensure thatthese problems can be solved in a comprehensive manner within the boundsdefined by project requirements, the designer's available experience,and the processing method selected. Front-end acceptance design stage102 generates a design specification defining a processing methodologyincluding selected pre-designed circuit blocks, design criteria, andinter-dependant design constraints.

[0106] Chip planning design stage 104 translates the designspecification from the output of front-end acceptance design stage 102into block specifications for each of the selected circuit blocks. Tasksexecuted in chip planning design stage 104 include: (1) developing plansfor chip design, assembly, and implementation focused on predictabilityof delays, routability, area, power dissipation, and timing, and (2)identifying and PATENT adjusting constraints. Specifically, based on thedesign criteria and inter-dependant constraints provided as the outputof front-end acceptance design stage 102, chip planning design stage 104provides chip planning within the bounds (such as requirements andconstraints) dictated at front-end acceptance. The inventive chipplanning design stage 104 considers one constraint at a time, and yetmeets the overall design criteria as specified by front-end acceptancedesign stage 102. Chip planning design stage 104 achieves this byforming the budget for each of the circuit blocks selected in front-endacceptance design stage 102, revising the specification for the circuitblock, and adjusting constraints within the processing method specifiedby front-end acceptance design stage 102. In contrast to the chipplanning design stage of the present invention, existing methodologieseither generate new functional blocks or change the processingtechnology to meet the design criteria, increasing design time andraising project risk. Chip planning design stage 104 also generatesspecifications for glue logic (i.e. the hardware that is required tointerconnect the selected circuit blocks), discussed in further detailbelow. Chip planning design stage 104 provides as output three types ofglue logic, including new glue logic blocks that occupy one or moreareas in a chip, distributed glue logic distributed into the selectedcircuit blocks, and top level block glue logic elements.

[0107] To seamlessly interconnect the selected circuit blocks, ifnecessary, block design stage 106 embeds an interface (called a collar)around each circuit block to form a standard interface. Since a circuitblock can be soft, firm, or hard, each collar may be soft, firm, or hardas well. Block design stage 106 output provides that: (1) all circuitblocks in the chip meet the constraints and budget, and fit intodictated chip design plans and architectures; (2) chip assembly designstage 108 is provided with all required models and views of all circuitblocks; (3) the design is enabled for developing methodologies and flowsfor authoring the new circuit blocks generated in the chip planningdesign stage 104, adapting legacy circuit blocks, and adapting thirdparty circuit blocks; and (4) the design fits into given chiparchitectures and budgets.

[0108] Chip assembly design stage 108 integrates circuit blocks totape-out the top-level design for design stage fabrication. Chipassembly design stage 108 includes the final placement of hard blocksand chip bus routing, as well as the completion of any global designdetails. Chip assembly design stage 108 does not begin until all circuitblocks are designed, modified, and integrated into the chip plan. Inputsfor chip assembly design stage 108 include power, area, and timingmargin specifications received from the front-end acceptance designstage 102 or chip planning design stage 104.

[0109] Verification design stage 110 ensures that the design at eachstage meets the customer functional requirements as detailed in thefunctional specification and chip test bench supplied at front-endacceptance design stage 102. Verification design stage 110 includesfunctional verification 112, timing verification 114, and physicalverification 116.

[0110] Functional verification step 112 ensures that the logic functionsand chip test benches for the selected circuit blocks at each stage ofthe design meet the functional requirements of the customerspecification. Functional verification can be performed during front-endacceptance design stage 102, chip planning design stage 104, blockdesign stage 106, or chip assembly design stage 108. Timing verificationensures that signal timing at each stage of the design is appropriate togenerate the logic functions and pass the tests specified in thecustomer's specification. Timing verification can be performed duringfront-end acceptance design stage 102, chip planning design stage 104,block design stage 106, or chip assembly design stage 108. Physicalverification ensures that the physical layout for the circuit designmeets the customer specification.

[0111] During the design process, front-end acceptance design stage 102,chip planning design stage 104, block design stage 106, and chipassembly design stage 108 not only perform their intended functions, butalso generate the information needed for functional verification 112,timing verification 114, and physical verification 116 which, together,comprise verification function 110. If any errors occur duringverification at a particular stage of the design process, these errorsare preferably corrected before going to the next stage.

[0112] Thus, at chip assembly design stage 108, the design process notonly generates a top-level design for fabricating a chip, but alsocompletes verifications of chip test benches for each of the circuitblocks used in the design and the overall chip test bench for the chip.

[0113] FIGS. 2-15 will now be described in summary form. Each of thesefigures provides a high level description of materials discussed ingreater detail below.

[0114] II. Front End Acceptance 102

[0115] Referring to FIG. 2, flowchart 200 illustrates the steps 210-216of front-end acceptance design stage 102, in accordance with the presentinvention.

[0116] III. Chip Planning 104

[0117] Chip planning design stage 104 includes the following modules:

[0118] (1) clock planning;

[0119] (2) bus identification and planning;

[0120] (3) power planning;

[0121] (4) I/O and analog/mixed-signal requirements;

[0122] (5) test planning;

[0123] (6) timing and floor planning; and

[0124] (7) bus verification.

[0125] Referring to FIG. 3, there is shown the clock-planning module, inaccordance with the present invention.

[0126] Referring to FIG. 4, there is shown the bus identification andplaning module, in accordance with the present invention.

[0127] Referring to FIG. 5, there is shown the power-planning module, inaccordance with the present invention.

[0128] Referring to FIG. 6, there is shown the I/O andanalog/mixed-signal requirements, in accordance with the presentinvention.

[0129] Referring to FIG. 7, there is shown the test-planning module, inaccordance with the present invention.

[0130] Referring to FIG. 8, there is shown the timing and floor-planningmodule, in accordance with the present invention.

[0131] IV. Block Planning 106

[0132] Referring to FIG. 9, there is shown the flow of the block designstage, in accordance with the present invention.

[0133] V. Chip Assembly 108

[0134] Referring to FIG. 10, there is shown the data flow of the chipassembly design stage, in accordance with the present invention.

[0135] Referring to FIG. 11, there is shown the task flow of the chipassembly design stage, in accordance with the present invention.

[0136] VI. Verification 110

[0137] Referring to FIGS. 12, 13, 14, and 15, there is shown thefunctional verification flow for the verification design stage of thepresent invention.

[0138] Scalable Methodology for Feasibility Assessment

[0139] Turning first to front-end assessment, FIG. 16 illustrates theinventive methodology to assess feasibility of a circuit design using aplurality of pre-designed circuit blocks, in accordance with the presentinvention.

[0140] In FIG. 16, the inputs for the methodology are originallydesigned to use field of use data as inputs. However, in assessing a newdesign project, new types of inputs 1, 2, and 3 need to be used toassess the feasibility of the new design project. To accommodate themethodology, the new types of inputs are processed so that themethodology can use the new types of inputs to perform feasibilityassessment for the new design project.

[0141]FIG. 17 shows the feasibility assessment result using themethodology shown in FIG. 16, in accordance with the present invention.FIG. 17 indicates risk on the vertical axis and time/cost along thehorizontal axis. According to the risk indicator, the risk of usingthese three types of new data increases slightly compared with the riskpresented when only using the field of use data. Also from FIG. 17, itcan be seen that a type 3 input has the greatest impact on risk.However, according to the time/cost indicator, by using these threetypes of new data, the time/cost increases greatly compared with therisk created by using only field of use data. By considering theramifications of the inventive risk v. time/cost calculus indicated inFIG. 17, the pre-staged blocks are pre-designed and qualified for properuse in the design methodology. The pre-staged design plan is preferablya section of an existing methodology, for example, a block-authoringpiece.

[0142]FIG. 18 shows a methodology to assess the feasibility of a circuitdesign using a plurality of pre-designed circuit blocks, in accordancewith the present invention. In FIG. 18, the inputs for the methodologyare originally designed to use field of use data as inputs. However, inassessing a new design project, new types of inputs X, Y, Z need to beused to assess the feasibility of the new design project. To accommodatethe new input types, the methodology is modified so that the new inputscan be used to perform feasibility assessment for the new designproject.

[0143]FIG. 19 illustrates the assessed feasibility obtained using theinventive methodology shown in FIG. 18, in accordance with the presentinvention. FIG. 19 indicates risk along the vertical axis and time/costalong the horizontal axis. According to the risk indicator, the riskprovided when using the three new input types increases greatly incomparison with the risk provided when only using field of use data.

[0144] Also from FIG. 19, we can see that a type Z input has thegreatest impact on risk. However, according to the time/cost indicator,the time/cost provided by additionally using these three types of newinputs increases moderately comparing with the time/cost by only usingthe field of use data.

[0145] The new types of inputs can be estimation data or implementationdata for the pre-designed circuits. Based on the results shown in FIGS.16-19, a system integrator can make tradeoff decisions.

[0146] Feasibility Assessment in the Front End Acceptance

[0147] The front-end acceptance (FEA) design stage 102 in FIG. 1involves feasibility and risk assessment of a proposed design. A designis feasible if the assessed criteria are within allowable risktolerance.

[0148] In a sense, the FEA is a process of design refinement to a pointat which the system integrator can assume the risk of accepting aproposed design. As such, it is the process of reduction oflack-of-knowledge and, therefore, error in the requested design's finaloutcome. As a starting point, the FEA process receives a set of designrequirements delivered by a customer, the integrator's risk profile foraccepting a design, a set of pre-designed blocks, and the integrator'sprevious knowledge of and experience with the pre-designed blocks. Thepre-designed blocks can be at various levels of resolution (hard, softor firm). The resolution, previous experience and understanding of ablock give rise to a large range of error-bounds in the prediction ofarea, power, performance, etc., across the blocks.

[0149] For each of the blocks, the design refinement may be presented inthree levels of resolution:

[0150] (1) integrator's field of experience (FOE),

[0151] (2) estimation using actual models and tools to execute thosemodels, and

[0152] (3) dip by taking a block into a higher level of designresolution than that at which it was received.

[0153] It should be noted that three levels of design resolution arearranged in ascending order as: soft, firm, and hard. Efficiency isachieved by providing a mechanism to conduct feasibility assessmentwithout needlessly refining all block and interconnect criteriapredictions.

[0154]FIG. 20 shows a flow diagram for an FEA process in accordance withthe present invention.

[0155] In FIG. 20, the FEA process includes three phases of feasibilityassessment, reflecting the three levels of design refinement discussedabove. These three phases are: coarse-grained assessment, medium-grainedassessment, and fine-grained assessment.

[0156] Coarse-grained assessment is a field of experience dominatedassessment based upon the design integrator's previous experience withsimilar designs. Coarse-grained assessment is especially suited to ten'sof blocks and system design options, and to situations where designestimation-error tolerance is on the order of fifty percent or more.Coarse analysis can be used to make a cursory examination of blocksbeing considered, where the estimation of interaction between blocks isnon-critical. At this phase, it is most likely that not all blocks beingconsidered are used in the final design.

[0157] Medium-grained assessment is an estimation-dominated assessment,to estimate by analytic formulation of behavior through equation orsimulation. It is suitable for from two to ten system design options,and to a situation where acceptable design estimation-error tolerance ison the order of 20%, and the integrator has an understanding of how theblocks interact. It can be used to examine the interaction betweenblocks critical to operational sufficiency of the design. In this phase,all blocks in consideration have a high probability of being used in thefinal design.

[0158] Most refined (fine-grained) assessment is a design-dip-dominatedassessment to make measurements from a refinement of block design.

[0159] Dipping is a process in which a new block is transformed into asoft block, a pre-designed soft block into a firm block, and apre-defined firm block into a hard block. Results are generated fromeither simulation, emulation or prototyping. Fine-grained assessment issuitable to all or part of a single-option chip design where acceptabledesign estimation-error tolerance is less than 5%, such as during finalresolution of critical issues for which existing design refinement isinsufficient. It can be used to examine a subset of chip behaviors orblock-interactions which need to be studied in detail to guaranteesufficiency or to guarantee that resolution provided by any existingsimulation model for the block is sufficient. It can also be used toexamine the failure of the block to meet design requirements, which willstrongly impact final design feasibility. In this phase, not every blockin consideration will be dipped; instead, substantially only thoseblocks that have critical impact on the FEA decision process are dipped.

[0160] In FIG. 20, the width of each triangle represents the error inprediction of the system FEA criteria. At each level of the assessment,the key is to refine as little as possible the FEA criteria whilereducing the designer's error so that an FEA decision can be madequickly. At each phase of the FEA process, the basic intent and strategyis the same, as listed below:

[0161] (1) Gather available information about the blocks underconsideration;

[0162] (2) Identify and refine locally those blocks most likely toimpact system-estimate error;

[0163] (3) Assess whether the design meets the FEA constraints. If so,stop the FEA process; and if not,

[0164] (4) Refine globally the block-estimates in the system if FEAconstraints are not met.

[0165] A key part of the FEA process illustrated in FIG. 20 is how tocalculate the acceptable global error (or overall error) in theprediction of system criteria, and identify which few blocks requireestimate refinement to bring the global error to within acceptablebounds. This calculation process requires three parameters:

[0166] (1) Estimate of the acceptable global error for making adecision;

[0167] (2) Estimate of the global error which will result from currentsystem analysis; and

[0168] (3) The sensitivity of the global error to the error inestimating a particular block in the design (also referred to as theblock-error impact).

[0169] The first parameter is defined by the risk-profile of the systemintegrator, the constraints supplied by the customer, and a goodprediction of the global error, which will result from basing a systemprediction upon the current state of data. The second and thirdparameters are all derived from building accurate Error Impact Curves.Referring to FIG. 21, there is illustrated the driving of the refinementprocess, given the error impact curves, in accordance with the presentinvention.

[0170] To further define the FEA process, the present invention usesfour basic assessment techniques:

[0171] 1. FEA Decision Process: Defining Data-In, Data-Out and theDecision Process based upon Data-Out. (i.e., How is Data-Out related tothe assessment of acceptable risk?);

[0172] 2. FEA Data Extraction Process: Moving from a complete set ofData-In for the abstraction level being considered to the generation ofData-Out;

[0173] 3. FEA Block-Refinement Identification: Defining a commonmechanism for establishing the System-Estimation Impact, given theEstimation-Error and Block Criticality within a system design. (i.e.,Highest potential impact blocks are refined further if the acceptancecriteria for the Decision Process are not met); and

[0174] 4. FEA Assessment-Axes Metrics: Defining the actual metrics to beused for each of the axes-of-acceptance associated with FEA. (i.e.,defining how the criticality of a block within a system is defined).

[0175] In the method and system of the present invention, a set ofestimate correctness curves are used to validate the FEA process. Eachof the estimate correctness curves is presented over an FEA axes, whichvisually provides the elements and criteria for validating the FEAprocess. To better explain the function of an estimate correctnesscurve, the following elements and criteria are defined. Collectively,these elements and criteria are referred to as the FEA Axes ofAcceptance. These definitions apply to both blocks and the overallsystem. Power per mode of operation (e.g., mW) Performance intra-cycledelay (e.g., ps/ns/us) latency (e.g., ns/us/ms) throughput(objects/second - e.g., 50 kB/sec) Area area including: gates, routing,perimeters, unused white-space (e.g., mils) Cost Non-recurrentengineering cost (e.g., U.S. $) Cost per Unit (e.g., U.S. $) ScheduleResource allocation (e.g., man-years) Deliverable timelines (time) RiskPossibility of error (%) Impact of errors (U.S. $, and/or time)

[0176] Before conducting the FEA process, the customer provides thesystem integrator with as much of the following information as possible:

[0177] (1) A set of circuit blocks which are either in soft, firm, orhard format;

[0178] (2) A set of simulators (estimators) or previous-experienceestimates for the blocks, along with error-tolerances for the estimates;

[0179] (3) A set of specifications describing the overall chipfunctionality and performance requirements; and

[0180] (4) A set of stipulations regarding acceptable schedule, cost,and risk for the project.

[0181] The customer may also provide:

[0182] (5) Behavioral definitions for any new blocks to be incorporatedinto the chip; and

[0183] (6) Identification of known critical issues.

[0184] Before conducting the FEA process, the system integrator should:

[0185] (1) Determine a risk profile by which design suitability isassessed, including:

[0186] a. Guard-Bands—The integrator's over-design margin for each ofthe FEA axes;

[0187] b. Acceptance Risk—Certainty that design will satisfyrequirements prior to accepting a customer request. This is simplyexpressed as a standard-deviation measure—the Aδ design-acceptance risk;and

[0188] c. Rejection Risk—Certainty that specified design is unable to beassembled and fabricated with available blocks. Note that rejection isactually a risky behavior for the system integrator: the risk beingtaken is that the rejected design was actually feasible even thoughinitial assessment made it appear doubtful. This is also expressed as astandard-deviation measure—the Rδ design-rejection risk.

[0189] (2) Verify that the submitted blocks, in combination with any newor third party blocks, are sufficient to meet the project constraintswithin acceptable limits of risk.

[0190] Referring to FIG. 22, an exemplary correctness curve estimate isshown, in accordance with the present invention. The horizontal axis isan FEA axis, which can represent any customer constraints or the overallconstraint for the system. To facilitate explanation, assume that theFEA axis represents power. The vertical axis represents estimatecorrectness. According to FIG. 22, the guardband of the power constraintis between the constraint-initially specified by the customer and theconstraint modified by the FEA process. Note that, in the example given,the design is rejected because the power constraint modified by theguardband lies within the rejection region. This is true even though thepower constraint initially specified is not in the rejection region.

[0191] If the modified power constraint had been between the Aδ and Rδmarkers, the FEA refinement process would have proceeded. This processwould continue to reduce the expected error variance (i.e., thepower-error variance, in this example) until an accept or rejectdecision can be made based on a refined estimate correctness curve.

[0192] Referring to FIG. 23, a process to validate an FEA is shown, inaccordance with the present invention. The inventive FEA validationprocess includes four phases:

[0193] 0. Pre-FOE Phase (not shown):

[0194] Obtain the customer design constraints for each of the FEA axesof acceptance. Modify each of these constraints by the requiredguard-band. These modified customer constraints are used only forverification of the FEA process, and are referred to simply as thedesign constraints.

[0195] 1. FOE Dominant Phase:

[0196] The system integrator commences FEA by combining together the FOEestimates and estimate-error tolerances to determine whether therequired constraints are guaranteed (confidence is higher than definedby: Aδ for a pass, or Rδ for a fail) to be met.

[0197] (a) If, despite consideration of third party blocks, constraintsare still violated, then the design is not possible. The systemintegrator must return to the customer with a set of options and theconstraints met by these configurations.

[0198] (b) If the constraints are met to within acceptable risk, the FEAprocess is complete.

[0199] (c) If there exists less-than-acceptable confidence of predictingthe passing or failure of the design, then the estimation phase mustcommence. To enter the estimation phase, the set of“most-likely-to-pass” design configurations (i.e., best) must beselected.

[0200] 2. Estimation Dominant Phase:

[0201] For the set of best designs derived from the FOE stage, anidentification of criticality must be made; i.e., given the errortolerances on each of the blocks involved, which are statistically themost likely to validate that the design has passed constraintvalidation. This will be a product of both the size of the variance ofthe FOE specification prediction for a block, and the impact that blockhas upon the design constraint in question. Estimation should proceed bystubbing-out as much of the non-critical design as possible, andgenerating design specific estimates for that which remains.

[0202] (a) Violation: Similar to procedure 1(a) discussed above.

[0203] (b) Satisfaction:: If the level of indeterminacy is unlikely tobe reduced further by increasing the accuracy of estimation (reducingthe amount of stubbing will not improve the estimate in anystatistically significant way, due to the fact that the error-toleranceis dominated by blocks already included in the estimation), or a fullestimate of the SOC design has been built given existing block models,then the best design must pass onto the dipping phase.

[0204] 3. Design-Dip Dominant Phase:

[0205] Refine the block estimate to which the global error is mostsensitive, then proceed as per the estimation phase. Continue iteratingthis process until the FEA is confirmed or denied. The definition ofstatistical criticality is similar.

[0206] Referring to FIG. 24, a refined estimate correctness curve usingthe inventive FEA design-property refinement process of the presentinvention is shown. Through the refinement process of moving from FEAphases 0 to 3, discussed above, the expected error variance on therefined estimate correctness curve is greatly reduced compared with thatof the estimate correctness curve shown in FIG. 22. Thus, a decision toaccept or reject may be made based on a refined estimate correctnesscurve, as shown in FIG. 24, whereas such a decision may or may not bemade based on the estimate correctness curve shown in FIG. 22.

[0207] If an FEA decision cannot be made based on the availableinformation and data at one phase of validation, the present inventionperforms a design-property refinement process to reduce the expectederror variance. Based on the refined data and information, the presentinvention performs the FEA validation at the next phase. Thedesign-property refinement process comprises the following threeaspects:

[0208] (1) FEA Data-Extraction Process;

[0209] (2) FEA Block-Refinement Identification; and

[0210] (3) FEA assessment-Axes Metrics.

[0211] Referring to FIG. 25, the FEA Data-Extraction Process is shown,in accordance with the present invention. There is a standardizedmechanism, or process, for establishing an “Estimation of System Impact”for prediction error associated with each block in a system design. Thismechanism, referred to as Block-Refinement Identification, enables therequired error-boundary on properties (the FEA Design Criteria—e.g.,power, area, performance, etc.) of any specific block to be determinedfor each refinement phase of FEA system-design assessment.

[0212] Let L(β) be the limit specified by the customer, as modified byany required Design Margin, for the design to satisfy FEA Criteria β.Let the expected value of the design as measured against FEA Criteria βbe E(β). The Design Decision Constraint, or the “maximum errortolerable”, for the design to be defined as pass/fail relative to theFEA Criteria β is given by: DDC(β)=|L(β)−E(β)|. For an expected “Pass”,E(β) itself must lie within the acceptance region for the FEA Criteria,and for an expected “Fail” E(β) must lie within the rejection region.Effectively, in the first case for a “Pass” we require: Aδ_(system)<DDC,and in the second case for a “Fail”: R

system<DDC. If the inequalities are unsatisfied, then the systemanalysis does not produce a decision-quality result.

[0213] It should be noted that, in general, the average estimate E(β) isthe final estimate of system-criteria β=0 as produced by the previousphase of system-assessment. i.e., The Medium Grain Assessment stagetakes as the average the final estimate of the Coarse Assessment Stage,the Fine Grain Assessment Stage takes as the average the final estimateof the Medium Grain Assessment Stage. To initiate the process, theCoarse Assessment Stage must be entered by first establishing acoarse-level expected-value estimate for each of the FEA Criteria.

[0214] For the system to be assessed relative to the Design DecisionConstraint (DDC) for a particular FEA Criteria β, a relationship must beestablished between the errors associated with block estimates and thetotal estimate error for the system. Note that the error associated witha block estimate is not just the inherent error of estimating theβ-criteria for the block, but also the specific influence of that blockand block-error upon the difficulty of estimating integration cost. Theerror in estimating the block is consequently scaled by asystem-criticality measure, C, which is a measure of the difficulty inintegrating the block based upon its properties or lack-or-definition(error) for FEA Criteria β. The determination as to the Pass (Fail) ofthe system is established through the relation of the set of{C_(block.δblock)|block ε system} to δ_(system) and the requiredinequalities: Aδ_(system)<DDC (Rδ_(system)<DDC) for each of the FEACriteria.

[0215] It should also be noted that to keep the inclusion of thecriticality measures C_(block) neutral relative the system inequalitiesexpressed above (i.e, δ_(system) is formulated from an expression whichcombines the criticality scaled block errors: C_(block.δblock)), thecriticality measures are normalized such that: Σ_(blocks)(C_(block))²=1.The process for assessing this varies slightly depending upon the classof system-property being assessed. From the perspective of FEA, thereare three classes of system-properties each described below:

[0216] Absolute (Block) Constraints (e.g., Intra-Cycle Delay,Throughput)

[0217] Relative (Block) Constraints (e.g., Power, Area, Latency, Cost,Schedule)

[0218] Mixed (Block) Constraints (e.g., Quality)

[0219] For simplicity, for an FEA Criteria β define BDC as the BlockDesign Constraint where: BDC_(block)=A.C_(block.δblock) in the case oftest for design acceptance, and BDC_(block)=R.C_(block.δblock) in thecase of test for design rejection. Then, for each FEA Criteria:

[0220] a. Absolute Constraint: To achieve a decision-quality result eachblock, or each block immersed in its immediate environment (e.g.,including routing load, etc.), must pass the DDC for the AbsoluteConstraint. Mathematically, achievement of a decision-quality result onan Absolute Constraint implies:

[0221] For all blocks ε in the system, BDC_(block)<DDC

[0222] b. Relative Constraints: A decision quality result is achieved ifthe square summation of block-design constraints throughout the systemis less than the square of the DDC. The term relative is used as theacceptable error of assessment for this constraint has the flexibilityof being partitioned amongst the blocks, which make up the entiresystem. Note that some assessment criteria of the Relative type may havemultiple constraints. An example of this is Latency, as there may beseveral critical paths, which contribute to a valid assessment of thecomplete system. Mathematically, achievement of a decision-qualityresult on a Relative Constraint implies Σ_(blocks)(BDC_(block))²<DDC²,assuming that all block-errors are Gaussian-distributed, independentrandom-variables.

[0223] c. Mixed Constraints: A mixed constraint is a type that involvesboth the relative and absolute types of constraint. For example Qualityis a mixed constraint. No block within a design can exceed a specifiedbound on its measure of quality, but the summation of all qualityassessment across the system must also fall to within a specified range.In this case there is both a DDC_(block) for the blocks, as well as aDDC_(system) for the overall system. Mathematically, for amixed-constraint system-property two criteria need to be satisfied:

[0224] (i) For All: block ε system, BDC_(block)<DDC_(block)

[0225] (ii) Σ_(blocks)(BDC_(block))²<(DDC_(system))²

[0226] Referring to FIG. 26, there is shown a process of identifying theneed for block-estimate refinement, in accordance with the presentinvention. As shown, there are three steps in FEA Block-RefinementIdentification, including:

[0227] 1: For each FEA assessment criteria of the Absolute or MixedConstraint type, the level of work required to achieve the absoluteerror tolerances (CIC's) is determined. As a by-product of refining amodel to satisfy the need of Absolute Constraints, some error-boundsassociated with Relative Constraints may also be reduced.

[0228] 2: Based upon the error predicted after the models are refined tosatisfy the Absolute Constraints, and Absolute part of the MixedConstraint Type, the remaining system-error tolerance (CIC) for thesystem are determined and partitioned amongst the separate IP blocks.The partitioning will be defined in such a way as to minimize the workrequired to build an estimate. The flexibility of this partitioning ismoderated by the defined criticality of contribution for each of theblocks within the assembled system. This defines the notion of errorimpact. Note that this problem must simultaneously optimize necessarywork against acceptable error-tolerance along each FEA axis.

[0229] 3: If at any stage system suitability cannot be determined usingthe proposed CIC's, these need to be tightened further and the processre-iterated either:

[0230] (a) for the block, if a specific absolute constraint isinsufficient, or

[0231] (b) for the system, if a relative constraint for the chip isinsufficient.

[0232] Referring to FIG. 27, there is shown an FEA Assessment-AxesMetric, containing a table defining the concept of Assessment-AxisCriticality (AAC), in accordance with the present invention andincluding, where appropriate, exemplary criticality measures. The AACrelates to Expected System-impact (ESI) through Expected EstimationError (EEE) based upon the following relation: ESI=AAC*EEE.

[0233] As shown in FIG. 27, the table contains five columns, as thefollowing:

[0234] (1) Assessment Axis FEA is measured based upon these criteria

[0235] (2) Constraint Type Each FEA Assessment Axis may have one ormultiple constraint-types associated with it

[0236] (3) Constraint Class Class as defined above

[0237] (4) Routing

[0238] Refinement Type of routing-refinement necessary to ensure thatthe impact of chip routing is of the same degree of error as thespecified block and system constraints

[0239] (5) Criticality Measure Standardized way of measuring thecriticality of a property associated with an FEA Assessment Axis

[0240] Some elements of the table make reference to Routing Criticality.Routing Criticality is defined for any output pin of a block or chipinput pad as Pin Routing Criticality=(Expected NetLength)*(Capacitance/Unit Length). Block Routing Criticality is the sumof Pin Routing Criticality across the output pins of a block.

[0241] The symbol: a denotes an effective-routing-area scalar whereby:α*(Routing Criticality) translates units and the scale of RoutingCriticality into an area-applicable number.

[0242] Power consumed as a consequence of routing requires an estimateof activity on the lines. This can be done at a block or pin level ofresolution. When applied to the block, the activity estimate is derivedfrom the average activity on the output lines of the block, denoted:E_(block).

[0243] A point connection counts as any fanout point unless severalfanout points are connected by use of a shared bus. A shared bus countsas a single distinct block. Routing criticality is a measure of theexpected difficulty in routing connections to a pin and, therefore, itis a measure of FEA uncertainty.

[0244] Note that many of the assessment axes might be identified asmixed constraints at some level of resolution; e.g., an area may bedefined as mixed after initial floor plan is defined and used topartition the SOC design chip-level constraints into block-levelconstraints. However, the dominant constraint type used during the rapidFEA period is listed.

[0245] The term Error used in the table refers to the bound on error asrelates to the property in question.

[0246] Organizing the Field of Experience Data

[0247] Designer experience is a crucial part in the system-decisionprocess of the BBD methodology. The BBD methodology extends the conceptof experience associated with a single key designer or architect to theconcept of “company design experience”. This general “pool” ofexperience is referred to as the BBD Field of Experience (FOE) of thepresent invention.

[0248] It is the purpose of BBD method to propose four concepts andmechanisms for the building and use of FOE. These concepts are:

[0249] a) Data Gathering—Definition of rigorous processes for obtainingand initiating FOE data.

[0250] b) Data Classification—Information classification and mechanismsfor developing relevant classifications. Such classification guaranteesthat gathered data may be statistically analyzed, extrapolated, andglobally refined as the amount of accumulated design-knowledgeincreases.

[0251] c) Data Certification—Definition of a process that builds thecorrect assurance of “trust” in what might otherwise be referred to as“rule-of-thumb” numbers. Certifying FOE data will guarantee thatestimates built from the FOE database are statistically well bounded.

[0252] d) Data Application—The mechanism for application of FOE to thedesign process. This is a part of Front End Acceptance for BBD.

[0253] Field of Experience Definition

[0254] In BBD, Field of Experience can be defined as compiled data frommeasurement of prior designs classified according to design styles,design purpose, and critical measurements of design characteristics.Critical characteristics may include: area, throughput, power andlatency. The definition of Experience-Based Estimation is systematicprediction based upon experience with similar designs or designbehaviors. It follows that the definition of FOE Estimation isExperience-Based Estimation using FOE data.

[0255] It should be noted that this is distinct from BBD Estimation inthat it does not imply the specific analysis of the design in question,or—where the hardware design is actually known from previousexposure—specific analysis of a new behavior requested of that hardware.For example, a DSP core may have been developed within a company and anFIR-Filter embedded routine run upon it in a previous instantiation ofthe core. It may then be requested that feasibility of an FFT algorithmrunning on that same core be considered. If that first rule-of-thumb isbased solely upon the previous algorithmic efficiency observed whenexecuting the FIR operation upon the design, but without entering intothe details highly specific to the FFT algorithm, then this is an FOEestimate.

[0256] Field of Experience must explicitly draw upon information derivedduring a set of previous design projects. FOE data must be able to becatalogued, stored and accessed through a standard database.

[0257] There are three different classes of experience-based data usedin design, each form of data being associated with a specific errorprofile:

[0258] a) Project Data—Designer-requested estimate at project time. Thedesigner does not draw upon the experience of others as logged in theFOE database, but more upon his own uncatalogued design experience.Error in the design estimate is given by a Designer-Error Variance,which has been observed for general designs. Designer-Error Variance isbuilt from measuring a general history of designers' ability toaccurately predict results.

[0259] b) Predicted Data—Within a design classification but without aspecific project in mind, a designer is requested to give his best-guessparameter-relationships for extending existing FOE data. In this case,the FOE data being extended may consist of as little as a singledesign-point. Error for this is in part specified by the designer's bestguess at the parameterization error, but also modified by the history ofdesigners' ability to accurately predict results. Assuming statisticalindependence, these error variances would be summed.

[0260] c) Collated Data—Collected, classified and parameterized datafrom a set of design experiences. There is a possibility of measurementerror directly associated with this data, but this is likely to beminor. The main error is defined as the difference between measuredresults and those predicted by the variation of data-parameters.

[0261] Note the Project Data is not a form of FOE data as it provides nomechanism to extend the current estimates to future designs.Furthermore, as Project Data is gathered at the commencement of aproject, not the completion, it is not verifiable against catalogueddesign experience. This implies that it is not certified. Any datagathered from Final Measurement of the design may be entered into theFOE database, and the accuracy of the Project Data versus FinalMeasurement be used to refine Designer Error Variance for the company.

[0262] Predicted Data are referred to as FOE seed-data. Predicted Datamay be immediately applied to FOE estimation on like designs.

[0263] A common classification of the types of data received must applyto both of the above sources of FOE data. Such common classificationpermits the quick identification and cataloging of received data.Initial classification-specification is regarded as the planning stagefor FOE, and the entering/gathering of data is the building stage. Asthe amount of information in the FOE database grows, the refinementprocess is applied to reduce error tolerances to within those beingobserved statistically. In parallel with all three of these stages isthe FOE certification process.

[0264] The parameters listed above are used to extrapolate fromexisting, general FOE data to derive project-specific FOE estimates.Such a relationship between extrapolated estimates and FOE data ispreferably defined for each design classification. Each parameter FOErelationship may be defined by a designer's personal experience (seePredicted Data above), or may be empirically specified throughcurve-fitting the FOE data if sufficient information is available.Parameters might include such technical variables as pipeline depth,degree of parallelism, bit-width, and clocking-speed.

[0265] It should be noted that FOE applies not only to design blocks,but also to the interconnect between the blocks. In such cases, FOE maybe specified as the cost of routing between blocks of one classificationand blocks of another. Like the application to blocks, FOE estimates forinterconnect may also be parameterized.

[0266] Estimating with Maximum Accuracy:

[0267] A key aspect of FOE is the generation of estimates of maximumaccuracy given the data provided. This is a twofold process:

[0268] a) Refinement—As mentioned above, refinement is the process ofreducing the error-of-estimate to within that being observedstatistically. That is, when the amount of FOE data in a specificcategory is small, the error tolerance for the data is large. This isnot due to an inherent error, but rather to the unknown (or untested)applicability of the parameterized data to other specific designs. Asthe number of examined designs increases, the statistical spread of datacan be measured directly against parameterized predictions. When a largenumber of cases are catalogued for a specific classification of design,then the accuracy of the parameterization method will be wellestablished. Identification of large correlated error (as opposed torandom spread of data) could motivate the re-thinking of the parameterrelationships.

[0269] b) Classification Collapse—The different classifications ofdesigns may be related by proximity to one another. For example, theButterfly FFT implementation may be one classification of design, butall FFT blocks may be regarded as closely proximal to this design. Ifthe number of data associated with a particular classification ofinterest is too small to be statistically significant, then closeproximity FOE data may be collapsed together to reduce the overallestimation error. The collapsing of classifications together will itselfinduce an error due to the slight difference in design types, but thestatistical improvement in terms of number of designs considered mayoverwhelm this difference-error. It is preferable to compute a curvesuch as that shown in FIG. 28, and from that pick the configuration ofbest error.

[0270] The process/use model for FOE is therefore as follows:

[0271] I. Choose Block Classifications applicable to block beingassessed

[0272] II. Does enough data exist for that classification? (i.e., is theExpected Error sufficient?)

[0273] Yes—Return the best FOE estimate and END

[0274] No—Proceed

[0275] III. Collapse categories of close proximity until estimate errorceases to improve

[0276] IV. Is the Expected Error sufficient for FOE estimation?

[0277] Yes—Return the best FOE estimate and END

[0278] No—Proceed

[0279] V. Ask the designer to generate his best guess for the design.(This may be a dip into the Estimation Phase of BBD.)

[0280] FOE Certifying

[0281] Certification of FOE is the process by which the FOE informationgathered is shown to be reliable. This certification process willestablish the error of estimation during the Building and Refinementstages.

[0282] There are two aspects of certification:

[0283] a) Certification of Completeness—all FEA metrics must bemeasurable through the parameterization schemes provided.

[0284] b) Certification of Accuracy—including experience measures fordesigner, and the definition of process to ensure accuracy of collecteddata.

[0285] Glue Logic

[0286] The present invention further discloses an improved glue logicdistribution and reduction methodology. The combination of threealternative glue logic distribution mechanisms comprises a preferredembodiment of the present invention. First, glue logic that is notincorporated into predesigned blocks can be duplicated into multiplecopies for distribution to the existing blocks. Second, logic that hasno affinity to a block at the top level can be left as small blocks,optimally placed to minimize effective gate monopolization, wiringcongestion, and floorplanning impact. Third, where the number of blocksexceeds the block place and route limitations, glue logic may beclustered into glue cluster blocks until the block count is reduced toan acceptable level.

[0287] Referring to FIG. 29, there is illustrated a circuit design viewwherein glue logic 2910 resides disadvantageously between interconnectedblocks, thereby rendering inefficient the use of significant areas ofsilicon real estate and creating significant wiring congestion.

[0288] Referring to FIG. 30, we will begin with a description of thepresent method for creating multiple copies of glue logic fordistribution to larger top-level blocks. If an element 3010 has outputnets driving multiple loads, the element is split into multiple elements3012, each having only a single load on the output. In turn, each input“cone” (not shown) driving the duplicated element is copied as well,until all block outputs are reached. Similarly, large input gates arereduced to trees of non-inverting two-input gates, with a two-input gateof the original function at the top of the tree. In this way,substantially more logic is dedicated to the previously much smallerglue logic function. However, by removing glue logic from the areasbetween the larger blocks, the larger blocks can be more efficientlyplaced, resulting in a net efficiency increase.

[0289] Any glue logic element that cannot be effectively duplicated fordistribution is then preferably merged into a larger block having theclosest affinity to the placed element. Glue logic merger is executed ina manner based on a number of criteria, the most significant of which iswhether the merger reduces the number of top-level pin-outs. Thus, whenmultiple copies are created, since most of the resulting logic iscomprised of two-input gates, merging such gates into blocks wherein onepin is connected to the block reduces the pin count by two. When two ormore blocks are equal candidates for merger, the block having the lowestpin density is preferably chosen. Finally, the lowest prioritypreferably goes to timing considerations.

[0290] Next, referring to FIG. 31, gates and small blocks 3110 thatcannot be merged are clustered into clusters 3112. Gates that cannot bemerged most likely have multiple loads on both their input and outputnets. By recombining gates with inputs having similar function, gatecount can be reduced.

[0291] The present invention further discloses a method to convertpre-designed circuit blocks into circuits having standardizedinterfaces.

[0292] The tasks performed in the block design stage 106 in FIG. 1include: (1) creating any missing abstracts for the selected circuitblocks, (2) embedding the circuit blocks into their respectivestandardized interfaces known as collars, and (3) creating a completeset of abstracts for the collared circuit blocks.

[0293] Referring to FIG. 32, a collaring process of embedding a circuitblock into a collar is shown, in accordance with the present invention.

[0294] In the BBD methodology, selected circuit blocks are the primaryinput components at the chip-level. The collaring process places acollar around each of the circuit blocks to create a standard interfacearound the boundary of the circuit block. To successfully integratecollared blocks into the chip-level, a complete set of abstracts has tobe created for the collared blocks. Before creating the complete set ofabstracts for the collared blocks, the system of the present inventionfirst forms any missing abstracts for the selected blocks, whereabstracts are models or views of the block, or collared block designsrequired by chip-level assembly or planning tools. Exemplary abstractsinclude:

[0295] (1) Static Timing Abstraction—TLF

[0296] (2) Layout Blockage File—LEF

[0297] (3) Models for Verification—Bolted-Bus-Block model

[0298] (4) Block layout constraints to the system

[0299] Referring to FIG. 33, creating a complete set of abstracts of acircuit block is illustrated, in accordance with the present invention,while FIG. 34 illustrates a combination of the features illustrated inFIGS. 32 and 33.

[0300] We will move next to a description of the collaring process,wherein it is assumed that a standard interface has been defined foreach type of the blocks to be used in design.

[0301] At a first step, the process checks whether each of the blockshas a completed block abstraction. If any of the blocks does not have acomplete block abstraction, the process forms a complete blockabstraction for the block.

[0302] Next, the process identifies a block type for each of the blocks.Specifically, a block can be: a memory type, a processor type, a powertype, or an analog/mixed signal type. However, a type of circuit blocksfrom different sources may have different interfaces that requiredifferent designs to connect other circuit blocks. For example, theprocessors designed by different vendors may have different interfacesand bus structure.

[0303] Next, the process associates the identified block with itsrespective interface standard.

[0304] Thereafter, the process creates a first collar portion containingthe components connectable to the specific interface of the identifiedblock.

[0305] At a next step, the process creates a second collar portion incompliance with the standard interface associated with the identifiedcircuit block.

[0306] The process then creates a third collar portion containing thecomponents for converting the specific interface into a formatconnectable to the standard interface and connecting the first collarportion with the second collar portion.

[0307] A block collar can be comprised of multiple layers. Currently,two collar layers (a block standard collar and a system-specific collar)have been defined for BBD and SOC, respectively. Referring to FIG. 35, acollar containing two layers is shown, one collar being standard for aparticular block, and the other being specific to the particular systemin which the block is to be deployed. The block standard collar containsthose interface components that can be defined without the knowledge ofthe specific system or the specific context in which it is beingintegrated. For example, in the context of BBD, a particular designgroup may decide that a JTAG-standard test interface is required in adesign. Thus, for all blocks to be used in any of the systems beingdesigned, a JTAG test interface is a standard and, thus, belongs in theblock standard collar. The system-specific collar (or adaptation collar)contains interface components which belongs to the block, but are systemor context specific. For example, the standard set for data lines maynot require a parity bit, but for a particular system being designed aparity bit is required on all data lines. The logic to generate theparity bit is associated with the block during chip planning and shouldreside in the system-specific collar.

[0308] Another distinction between the two collar layers in BBD is thatthe block standard collar can be put on prior to front end acceptanceand chip planning (chip planning may require that an initial collar isdesigned as part of a dipping process to better perform the chipplanning functions required), but the system-specific collar can only beadded after chip planning.

[0309] A more subtle difference between the two collar types is that thestandards set for the block standard collar may be much narrower inscope than the standards set in SOC. For example, a certain powerinterface can be a standard for BBD, but only for a particular company,and the other companies do not need to conform to that standard powerinterface for the block. Consequently, the blocks from outside of thecompany need a system-specific collar, which converts the standard powerinterface to the company one. This is contrasted with SOC, where anindustry-wide power interface standard exists and resides in the blockstandard collar. The ultimate goal in SOC is to create a standard collarthat is an industry-wide standard. A block that has such a collar can becalled a socketized block. In the future, if all the aspects of thecollar are industry-wide, there will be no need for an additionallayering of system-specific collar, thus bringing the block closer tothe ideal of plug-and-play.

[0310] Another dimension to the system-specific collar is that, althoughit is intended to be designed after chip planning, one can speed up thechip integration process by making a system-specific collar in chipplanning, wherein the parameters for capturing the ranges that thesystem-specific collar will have to be targeted. This speeds up theintegration process since, after chip planning, only the parameters needto be varied while the system-specific collar does not have to bere-designed from scratch.

[0311] The collars and blocks can be in various combinations of soft,firm, and hard. Just as there are advantages and disadvantages as to thehardness of a block, there are advantages and disadvantages tocombinations of softness, firmness, and hardness of the collars. Forexample, if the block itself is soft, it may be suitable to leave theblock standard collar soft so that when the system-specific collar isadded, the entire block can be synthesized, placed and routed flat forthe final conversion to layout. Whereas if a block is hard, it may besuitable to use a hard block standard collar to handle predominatelyphysical interface issues with only a small amount of standardfunctional changes, since a soft system-specific collar to handle thesystem-specific issues mostly involves functional changes.

[0312] A collar transforms a block-specific interface into a standardinterface in the following ways:

[0313] (1) transforming the physical configurations specific to theblock into standard physical configurations, including pin layer, pinlocation, and pin separation;

[0314] (2) transforming the power supply specific to the block into astandard power supply, including power loading and power physicallocation;

[0315] (3) transforming the test process specific to the block into astandard test process, including test access port (TAP) controller andtest protocol;

[0316] (4) transforming the timing specific to the block into a standardtiming, including setup and hold time, flip-flop, or latch;

[0317] (5) transforming the clock ports specific to the block intostandard clock ports, including the loading of each of the clock ports;

[0318] (6) transforming data/control signals specific to the block intostandard data/control signals, including standardizing signalpositive/negative assertion; and

[0319] (7) transforming the bus interface specific to the block into astandard bus interface, by adding registers for blocks expecting validinput on all cycles, big-endian or little-endian (a big-endian has the 0bit on the left end of the data unit; a little-endian's is on theright), and converting bit width.

[0320] In addition, a collar may contain components (glue logic, asdescribed above) for performing extra functions for a collared block.Glue can exist in three levels: (1) the glue deployed into a collar, (2)the glue combined at chip-level, and (3) the glue deployed in one ormore mini-blocks at chip-level. Specifically, glue logic can includeanything from simple functional translators (e.g., NAND gates along eachof the bit lines) to more complicated functions (e.g., registers,accumulators, etc.). Although glue-logic can be of arbitrary size, ifthe glue size becomes significant relative to the block, estimates madeduring front-end assembly and chip planning may become inaccuratebecause glue size was not considered. A constraint may need to put onthe relative size of the glue to the block.

[0321] A set of assumptions are used in the collaring process, asfollows:

[0322] (1) The decision of whether or not to add glue logic is made inchip planning;

[0323] (2) Of the three types of glue logic (glue put into collars;combination glue at chip level; glue put in mini-blocks at chip level),the collaring process preferably only addresses glue put into collars;

[0324] (3) Aspect ratio issues are handled during synthesis (not inblock collaring); and

[0325] (4) For BBD, the output of a collared block is layout.

[0326] Referring to FIG. 36, a logic view between a collar 602 and ablock 604 is shown, illustrating some exemplary functions of a collardiscussed above in accordance with the present invention.

[0327] As shown in FIG. 36, the collar 602 includes three portionsperforming three different functions. The first portion containscomponents that is connectable to the specific interface around theboundary of the block 604. The second portion contains the input outputcomponents in compliance with a standard, and the third portion containscomponents to convert the outputs from block 604 into the standard.

[0328] Specifically, in collar 602, the bus interface 606 combines twoone-directional buses 608 and 610 into a bi-directional bus 612. TestAccess Port 614 is connected to input 616 to collect the informationfrom and perform testing on block 604. The gate 618 inverts the incomingsignal to a format suitable for block 604, as received by gates 619, andgates 620-624 perform clock buffering.

[0329] Referring to FIG. 37, a physical view between a collar 702 and ablock 704 is shown, illustrating some exemplary functions of a collardiscussed above in accordance with the present invention. In FIG. 37,collar 702 and block 704 both contain multiple metal layers. A powerstandard exists for deploying the Vdd voltage on metal layer 3 (M3) andGND on metal layer 4 (M4). If block 704 does not comply with the powerstandard, collar 702 converts the power to comply. The region 706 sets apin spacing/layer standard. If block 704 does not comply with the pinspacing/layer standard, collar 702 converts it to comply with the pinspacing/layer standard. Collar 702 also contains glue 708 in a hardstate.

[0330] Referring next to FIG. 39, a system design 800 is shown withoutusing the collaring process of the present invention. As shown in FIG.38, the system design 800 is composed of four circuit blocks A, B, C,and D. Each arrow line connected to a block represents a constraint todesign an interface for that block. Thus, if a system is composed of ncircuit blocks (n=4 in this example), the interface for any particularblock may need to satisfy up to n−1 sets of constraints. Therefore, thetotal number of constraints that need to be satisfied for all blocks is0(n2).

[0331] Referring to FIG. 40, a system design 900 is shown using thecollaring process of the present invention. System design 900 iscomposed of four circuit blocks A, B, C, and D. Each arrow lineconnected to a block represents a constraint to design an interface forthat block. Using the collaring process of the present invention, eachblock needs only to satisfy one set of constraints defined by thecollaring interface. Thus, if a system is composed of n circuit blocks(n=4 in this example), the-total number of constraints that need to besatisfied for all blocks is 0(n).

[0332] Referring to FIG. 38, a computer system 1000 for performing thesteps for collaring and the other inventive BBD processes discussedherein is shown in accordance with the present invention. The computersystem 1000 includes a system bus 1001, a processing unit 1002, a memorydevice 1004, a disk drive interface 1006, a hard disk 1008, a displayinterface 1010, a display monitor 1012, a serial bus interface 1014, amouse 1016, and a keyboard 1018.

[0333] The hard disk 1008 is coupled to the disk drive interface 1006;the monitor display 1012 is coupled to the display interface 1010; andthe mouse 1016 and keyboard 1018 are coupled to the serial bus interface1014. Coupled to the system bus 1001 are the processing unit 1002, thememory device 1004, the disk drive interface 1006, and the displayinterface 1010.

[0334] Memory device 1004 stores data and programs. Operating togetherwith the disk drive interface 1006, the hard disk 1008 also stores dataand programs. However, memory device 1004 has faster access speed thanhard disk 1008, while the hard disk 1008 normally has higher capacitythan memory device 1004.

[0335] Operating together with the display interface 1010, the displaymonitor 1012 provides visual interfaces between the programs executedand users, and displays the outputs generated by the programs. Operatingtogether with the serial bus interface 1014, the mouse 1016 and keyboard1018 provide inputs to the computer system 1000.

[0336] The processing unit 1002, which may include more than oneprocessor, controls the operations of the computer system 1000 byexecuting the programs stored in the memory device 1004 and hard disk1008. The processing unit also controls the transmissions of data andprograms between the memory device 1004 and the hard disk 1008.

[0337] In the present invention, the programs for performing the stepsdiscussed herein can be stored in memory device 1004 or hard disk 1008,and executed by the processing unit 1002, as will be understood by thoseskilled in the art to which the present invention pertains.

[0338] Bus Identification and Planning

[0339] The methodology of the present invention also provides formeeting the performance requirements of the overall design of the systemdesired by the end user or design team, as defined during front endacceptance (described above). While performance dictates the primaryconsideration for the design methodology of the present invention, asecondary consideration is reducing the gate count during bus typeselection, since bus size can vary between available bus types such thata large, simple bus consumes more logic than a smaller, more complexone.

[0340] Turning first to FIG. 41, there is illustrated a series of stepscomprising the method of the present invention. At step 4110, Front-EndAcceptance of the customer's initial specification is completed. Thisstep has been described in detail above. Next, at step 4112, predefinedbus requirements are analyzed, as explained below. At step 4114, busclustering is planned while variables including latency, bandwidth,direction, and existing interfaces for each of the blocks are analyzedas well, making reference at step 4116 to a bus taxonomy referencelibrary.

[0341] Next, at step 4118, new bus specifications are developed and atstep 4120 the new specifications are verified, including generation of acompliance suite and bus model verification substep. Steps 4118 and 4120are performed with reference to block prestaging step 4122, wherein newblock specifications covering arbiters and bridges are created, blockspecifications, including collars, are modified, glue specifications aredefined and testbenches are created.

[0342] We will begin with a discussion of bus planning, includingtranslating front-end specifications into top-level bus specifications.In the available art, system designers start with a high-levelfunctional model or specification of the system being designed. Usingsystem expertise and knowledge of similar systems, the designerconstructs a high-level diagram of the bus structure for the design. Thedesigner usually has a rough idea of the traffic on each of the buses,and can estimate how many buses and of what complexity are needed. Busesare designed to meet required system performance while minimizinginterface logic and design effort. Designers then use this architectureto create a bus functional model to verify that the design operates asdefined in the specification. This traditional process has beendifficult to quantify because results vary with the expertise and pastexperience of the designer. The tasks defined herein apply a formalstructure to the process of defining bus structures in chip design.However, these tasks require at least the average level of skill in therelevant bus and system development arts to achieve the best results.

[0343] Bus Protocols

[0344] Buses provide the preferred communication medium between circuitblocks in a design. A bus, in its simplest form, can be a collection ofpoint-to-point connections that require little logic but many wires. Asimple bus transfers data between blocks at every clock cycle. Whilesome blocks might require this type of information transfer, most blocksin a system need information from other blocks only occasionally. Andsince chip pins are very expensive in large system designs, buses arenormally used to reduce the number of chip pins needed and to allowperiodic communication between many different blocks in a system withlittle loss in performance. To do this, designers must add logic to eachof the blocks to keep track of data transfer scheduling issues, such as:which block can use the bus wires; what block the data is being sent to;when the sender sends the data; and whether the receiver gets the data.These issues are handled by control signals on the bus and theestablishment of a procedure for controlling communication betweenblocks (the bus protocol).

[0345] Two examples of bus protocol are the peripheral bus and thepacket network. In a simple peripheral bus protocol, one device controlsthe bus. All information and data flows through this device, whichdecides, one case at a time, which block will send or receive data.Although peripheral bus processing requires relatively little logic, itdoes not use bus wires efficiently, and is not very flexible. Packetnetwork protocols are relatively complex. All the information aboutwhich block sent the data and which block must receive it is stored withthe data in a packet. Packet protocols let any block send data to anyother block at any time. This protocol is very flexible and uses the buswires efficiently, but each block needs a lot of logic to know when tosend packets and decipher the packets it receives. Other bus protocolshave different levels of flexibility, utilization, and latency (initialdelay in transferring information from one block to another on the bus).A taxonomy for different bus types and their protocols is provided inFIG. 59.

[0346] The BBD bus design methodology of the present inventionpreferably uses defined bus types. The designer is not expected todevelop buses from scratch unless they are part of an authored block.Also, the designer preferably logically connects blocks to existing,well-defined bus types rather than creating complex buses. The BBDmethodology of the present invention therefore treats buses as signalconnections between blocks. The logic for the bus is preferablydistributed among the blocks in the design, as is the glue logic forallowing the buses to communicate outside the buses, as described hereinabove in the glue logic section.

[0347] All logical interconnect is treated as either simple or complexbuses. Simple forms of interconnection are defined by the bus connectionrules, but a specific protocol for complex buses is preferably notdefined. The BBD methodology of the present invention preferablysupports buses that: have hierarchy; are completely contained withinblocks; have wires external to blocks; are completely contained withinone level of logical hierarchy; are completely contained within onelevel of physical hierarchy; are compliant with VSI's on-chip bus (OCB)attributes specification; and are verified with compliance transactionvectors. Also, many of the out-of-scope conditions for BBD arepreferably supported in SOC methodologies under the present invention.

[0348] Buses are preferably either completely contained within blocks ordefined as interconnect at the top hierarchy level. Buses that aredefined at the top level are created at that level, allowing buscomponents to be distributed among and within the blocks.

[0349] To define buses for a BBD chip, the following steps are executed,each of which will be described in detail below:

[0350] Extract Bus Requirements

[0351] Define Buses Based on Clustering

[0352] Select Buses

[0353] Specify the Bus Design

[0354] Reference the Bus Taxonomy

[0355] Verify Bus Selection

[0356] Block Design Assumptions

[0357] In the BBD methodology, when the designer specifies the busdesign, he or she must connect to block structures. This task assumesthat if a firm or hard block contains a specific bus interface, thatinterface is soft, as defined above with reference to collars. It alsoassumes that blocks of all types contain a simplified interface betweenthe bus interface logic and the actual function of the block. This isnot an unreasonable assumption for peripheral blocks because manythird-party block providers have created their own simple interface sousers can add bus interface logic. Blocks that are tailored to multipledesigns have separate internal functions and bus interface logic. Theinternal interface allows one to reuse these blocks with differentbuses. When a hard block has specific bus interface logic that cannot beseparated from its internal function, a more complex bus protocoltranslation must be added to the block. In either case, the resultingbus interface logic becomes part of the soft collar created during blockdesign.

[0358] Extracting Bus Requirements

[0359] Data received from the front-end acceptance task includes the busnets, signal nets, and pins on each of the blocks. There are fourcategories of signal nets: 1) predefined bus signals, which are blockpins and nets comprising a bus, such as a PCI or AMBA bus, required bycertain blocks such as processors; 2) bus signals, which are block pinsand nets that must be buses, such as Read and Write signals; 3) possiblebus signals, which are block pins and nets that might be wires or buses;and 4) signals, which are wire nets and are not dealt with by buses.

[0360] When the designer has determined the signal types, data receivedfrom the front-end acceptance task is organized according to these fourtypes of signal nets. For type 1 and 2 nets, the data necessary tocreate a bus must either be provided by the customer or otherwiseavailable. The required data is further defined in VSI's On-Chip Bus(OCB) Attributes Specification OCB1 1.0, which is incorporated herein byreference.

[0361] In additional, each bus that is specified or might be used in thedesign must have: a complete user's guide sufficient to create the bus;an implementation guide that defines the physical requirements for thebus; a complete set of simulation tools to test and verify the bus; anda list of technical attributes and how the bus compares with the list.Also, to create buses that comply with the VSI's On-Chip Bus AttributesSpecification, vendors must provide the documentation and modelsdescribed below.

[0362] User's Guide and Simulation Tools

[0363] The user's guide and simulation tools are used in bus design tobuild and test bus components. The set of simulation tools includesmodels written in behavioral Verilog and/or VHDL for the followingelements: bus master; bus slave; bus support functions (arbiter, addressdecoder); and standard bus bridges. These are used to verify the bus, asdescribed herein in the section related to bus verification.

[0364] Implementation Guide

[0365] The implementation guide is used in block design, chip assembly,and subsequent tasks in chip design planning to describe the attributesof the buses. The following information is passed to block design aspart of the block specifications: special cells required; physicalproperties of the cells; bus multiplexing or steering options; memorymap; power distribution; and timing guidelines. Timing and maximumloading guidelines are also used in subsequent steps in chip designplanning. Timing guidelines, maximum loading, and restrictions on buslayout or wiring are passed to the chip assembly task for use in busimplementation.

[0366] Technical Attributes List

[0367] The technical attributes must be translated into a form that canbe maintained as bus attributes in the bus taxonomy reference library.The bus taxonomy reference and the bus type table are therefore used bythe designer to choose the bus types. For predefined bus signals, thedesigner checks to insure that the required connections can meet themaximum loading and timing guidelines, and that bus layout and wiringrestrictions can be met during chip assembly. If not, the design is sentback to the front-end acceptance task to be modified by the customer.

[0368] Defining Buses Based on Clustering

[0369] To define buses based on clustering, the designer uses theinterconnect bandwidths and latencies received at front-end acceptance.This step determines, for each of the clusters and blocks within theclusters, the latency, bandwidth, existing bus interface types, anddirection of data flow. This information is then passed to the nextstep, selecting buses.

[0370] A bus hierarchy is defined by clustering the highest bandwidthand lowest latency bus interconnect. Possible bus signals that arepoint-to-point nets can be eliminated from this and subsequent busanalysis and design, since these signals are provided directly to thechip assembly task for routing.

[0371] Create the Communication Manager Behavioral Model

[0372] The behavioral model of the chip as verified contains behavioralmodels and an abstract model of the interconnect between blocks.Typically, this interconnect is a software mechanism that transfers dataamong the test bench and blocks. Ideally, it is a form of communicationmanager, possibly a scheduler, to which all the blocks are connected. Atthe other extreme, the interconnect may also be a directly connectedpoint-to-point interface in the behavioral model.

[0373] The communication manager or, as referred to hereafter, thescheduler, is usually at the top level of the simulation module.Pseudocode for such a scheduler might look like this:

[0374] While queue is not empty Do;

[0375] Get next transaction from queue;

[0376] Get target block from transaction;

[0377] Call Target Block(transaction);

[0378] End;

[0379] In this pseudocode example, each block does the following:

[0380] Target Block (transaction);

[0381] Do block's function;

[0382] Add new transactions to the queue;

[0383] End;

[0384] At this code level, neither timing or bus size are defined. Allcommunication is done in transactions or by transferring informationpackets of any size. The transactions might include possible bus signalsand non-bus wires so that all communication between blocks goes throughthe scheduler.

[0385] Alternatively, the designer may modify the block pseudocode tosend and read the non-bus signals asynchronously. In this case, eachblock does the following:

[0386] Target Block (transaction);

[0387] Get non-bus signal values from top level;

[0388] Do block's function;

[0389] Add new transactions to the queue;

[0390] Apply new non-bus signal values to top level;

[0391] End

[0392] It should be noted that, for the sake of simplicity, theseexamples do not include non-bus signals. However, the designer can makesimilar adjustments to the examples that follow to include non-bussignals.

[0393] A pattern set is a collection of vectors in a test bench thatforce one block to communicate with another block. The test bench mustinclude enough pattern sets to execute the functionality of the entirechip. The designer must assign target performance levels to each of thepattern sets at a coarse level. For example, if there is frame data foran MPEG decoder in one pattern set, the designer must be able to definehow long the target hardware takes to process the frames in that set. Ifthe designer knows that the output rate must be about 30 frames persecond, the processing rate must exceed that number. These performancetargets are used in the subsequent stages of this process to define therequired bus bandwidths.

[0394] The blocks selected for the chip must have some cycle-approximateperformance specifications. If the behavioral models do not already havethese specifications, they should be incorporated into the model in thisstep.

[0395]FIG. 42 illustrates the internal structure of the interconnectsection of the behavioral model. First, the test bench and requirementsare received. Next, the preliminary scheduler is created. Interconnectmanager/scheduler 4210 transfers information between the blocks in thedesign and schedules their execution. Interconnect 4210 is thenmodified, and modified interconnect manager 4212 includes statisticsgathering and a delay matrix that is added as the model is adjusted tocycle-approximate operation. Finally, the test bench is again utilizedfor testing and design iteration. The details of these modifications aredescribed in the sections that follow.

[0396] Modify the Model to Account for Latency

[0397] Some designs have no specific latency requirement. Other designs,such as hubs and switches, are sensitive to data latency (the length oftime it takes the first unit of data to go from the sender to thereceiver). Most network devices, especially asynchronous transfer mode(ATM) devices, have specific latency requirements for informationtransfer, which translates into tight latency requirements for thecomponents within the networks and for the buses. Once the designerknows the latency requirements for the design, he or she adjusts theinterconnect model as follows. First two matrixes are created for eachpattern set that specify 1) the amount of data to be transferred betweenblocks, and 2) the number of transactions executed. Second, a matrix iscreated for each pattern set that specifies cycle count approximations.This second step is not necessary for designs with no latencyrequirements.

[0398] Data Transfer Matrix

[0399] To create a data transfer matrix, the designer first adds theamount of data that is being transferred from one block to another tothe communications manager model. Next, using a spreadsheet tool, thedesigner accumulate this data in a table for each pattern set.

[0400] For example, the table for a chip with three blocks and a testbench would be a 4×4 from/to table with the sum of all data transferred,in bytes, in each entry in the table. The diagonal would be all zeros.It should be noted that a more practical model takes into considerationthe buses going into and out of the chip, so the test bench wouldprobably have more than one entry on each axis.

[0401] An example of a data transfer matrix is illustrated in the tableof FIG. 43. The design behind this matrix has three blocks and threeports for the test bench: an interface to external memory, a PCIinterface, and a parallel I/O interface. As shown in the table, the datatransferred from Block 1 to Block 2 is 10,000 bytes, and the datatransferred from Block 2 to Block 1 is 8,000 bytes.

[0402] Thus, the first step in creating a data transfer matrix is tocreate a table, with a count of all transactions, as illustrated in FIG.44, showing transactions for exemplary Pattern Set X.

[0403] To create the tables illustrated in FIGS. 43 and 44, the designermay modify the scheduler pseudocode as follows:

[0404] While queue is not empty Do;

[0405] Get next transaction from queue;

[0406] Get sender block from transactions;

[0407] Get target block from transaction;

[0408] Get Transaction byte count;

[0409] Transactions Matrix (sender,target)=TransactionsMatrix(sender,target)+1;

[0410] Transactions Matrix (sender,target)=TransactionsMatrix(sender,target)+Transaction byte count;

[0411] Call Target Block(transaction);

[0412] End;

[0413] Because non-bus block-to-block wires have some delay (typically,at least one clock cycle), these are preferably added as separatetransactions in the timing queue, in addition to the bus transactions.

[0414] Latency Matrix

[0415] Since the clock cycle time for each block has already beendefined at front-end acceptance, the designer can then translate rawperformance into cycle counts as follows:

[0416] 1. To reflect the cycle-approximate operation defined in theirspecifications, the designer adds the estimated clock cycles for eachblock to its existing behavioral model. This step is preferably executedbefore sending the block to the block design task, but afterverification.

[0417] 2. The designer integrates the blocks back into the chip model.The chip model will then have cycle-approximate blocks with no timedefined in the interconnect.

[0418] 3. The designer uses a spreadsheet to set up a table similar tothat illustrated in FIGS. 43 and 44. Instead of the number of bytestransferred, the designer specifies the number of cycles each transfertakes, from the time the data is available to the time the data arrivesat the next block or test bench (latency).

[0419] 4. he designer modifies the interconnect model to use theperformance values illustrated in the new table.

[0420]FIG. 45 illustrates an exemplary latency matrix. A pseudo codeexample of these modifications is shown below:

[0421] While queue is not empty Do;

[0422] Get next transaction from queue;

[0423] Get time from transaction;

[0424] Get target block from transaction;

[0425] Call Target Block(transaction, time);

[0426] End;

[0427] Where each block does the following:

[0428] Target Block(transaction,time);

[0429] Do block's function;

[0430] Set Transaction times to time+delay+Latency(this block, target);

[0431] Sort new transactions to the queue;

[0432] End

[0433] It should be noted that the entries that read “0” in FIG. 44indicate that no data is transferred and as such are not applicable tothe latency matrix.

[0434] 5. The designer modifies the test bench to include the chiplatency requirements with estimated interconnect cycle count delaysusing knowledge of the design data flow.

[0435] 6. The designer simulates the design to see if it meets the cyclerequirements.

[0436] 7. The designer modifies the latency matrix, and repeats theverification process until the cycle requirements of the chip are met.

[0437] To create a table with the maximum cycle counts available foreach type of bus transfer, the designer should use large cycle counts tobegin with and reduce them until the specifications are met, sincetighter latency requirements translate into more gate-intensive businterconnect schemes.

[0438] Determine the Cluster Measure

[0439] Next, to reflect the natural clustering of the data, the designerreorganizes the data transfer matrix by moving the largest countsclosest to the center diagonal. There are a number of ways to performthis process; the preferred method is referred to herein as pivoting.The purpose of pivoting is to cluster blocks with the highest transferrates to minimize the number of pins required. The designer may set up aspreadsheet to do the calculations automatically.

[0440] To measure how effective clustering is, each site in the datatransfer matrix must be accurately weighted. This example uses adistance matrix, illustrated in FIG. 46, to weight the sites. In thetable of FIG. 46, each cell contains the square of the distance thatcell is from the diagonal. Other measures to weight the data transfermatrix sites may be used, however, the square of the distance ispreferred since it has been shown, in placement algorithms, to convergequickly while allowing some mobility of elements in the system, whichhigher-order measures restrict.

[0441] Next, the designer multiplies each cell in the data transfermatrix by its corresponding cell in the distance matrix and adds all thevalues for all the cells together. The result is the cluster measure.The cluster measure of the matrix in the table of FIG. 43 is 428,200.The lower the cluster measure, the more effective the bus clustering.

[0442] Pivot Blocks

[0443] To try to get a lower cluster measure, the designer should pivotthe data transfer matrix by swapping rows one by one and recalculatingthe cluster measure after every swap to see if the cluster measureimproves. One can swap rows by performing a sort, where the sites areelements in a list to be sorted, as illustrated in pseudocode below:

[0444] Get Current cluster measure of matrix;

[0445] Do for Current site=site 1 to n−1 in the matrix;

[0446] Do for Next site=Current site+1 to n in the matrix;

[0447] Swap Next site with Current site;

[0448] Get Next cluster measure of matrix;

[0449] If Next cluster measure>Current cluster measure

[0450] Then Swap Next site with Current site back to original location.

[0451] Else

[0452] Current cluster measure=Next cluster measure;

[0453] End

[0454] End;

[0455] This sort is similar to a quadratic placement algorithm, althoughthe interconnect is bandwidth instead of connections. The designer canuse other methods that provide similar results instead of this one.

[0456] Pivoting as illustrated above preferably produces, for example,the matrix of FIG. 47, with an improved cluster measure of 117,000. Itshould be noted that, in this idealized example, components do notcreate information. Components write what they read, so the column androw totals match, except for block 3 and the PIO. This may not be thecase for use in the field.

[0457] The designer can then use a table like that illustrated in FIG.47 to define the bus clusters. This example shows a high rate of datatransfer between block 1, block 2, the PCI, and memory. These componentsmust therefore be on a high-speed bus. Because there is a low datatransfer rate between block 3 and the PIO, these design elements can beon a low-speed bus.

[0458] The PIO is output-only, but all the other components arebidirectional. Because the components inside and outside the clustersmust communicate, the designer must create a bridge between the twobuses, as illustrated in FIG. 48.

[0459] Defining Buses Based On Clustering

[0460] Initial clustering preferably must include all predefined bussignal nets. The designer can pivot within the clusters to show thenatural internal subclusters, but, unless more than one bus type isdefined for these signals, they should be treated as one cluster in thenext task.

[0461] Where a processor's system and peripheral buses are defined, theclusters are broken into a system bus and a peripheral bus or buses,based on the clustering information. For example if the bus matrix inthe table of FIG. 47 is composed of predefined bus signal nets, theinitial clustering contains the whole matrix. If more than one bus isdefined, the blocks that need to be on a high-speed bus form one bus andthe rest form another bus. This partition is then passed to the nexttask.

[0462] If there are no predefined bus connections, buses are defined ina manner based upon the cluster information. The pivoted matrix usuallyhas groups of adjacent blocks with relatively high levels ofcommunication between them compared to other adjacent blocks. The tablein FIG. 49 illustrates this kind of clustering, similar to the previouspivoted matrix. FIG. 49 is based upon a different example from thosepreviously shown, to make the clustering process clearer. It should benoted that “##” represents a large number.

[0463] In this example, blocks A, B, and C form one independent buscluster because there is a high rate of communication among the threeblocks and there is no communication between these blocks and blocks Dthrough H. Blocks D, E, and F form another cluster because there is ahigh rate of communication between all three. Also, blocks D, E, and Fcould form two separate buses: a point-to-point bus between D and E, andanother between E and F. Blocks G and H form a third cluster. There arelower-bandwidth connections between the EF pair and the GH pair.Depending on the amount of data transfer, E, F, G, and H might be on onebus or on-two separate EF and GH buses with a bidirectional bridgebetween them for lower-level communication.

[0464] To choose from a number of different clustering options, thefollowing guidelines are followed:

[0465] 1. Identify the cut points between blocks to determine possibleclusters. A cut point a high communication area from a relatively lowcommunication area. A cut between C and D in the matrix in FIG. 49produces the diagram illustrated in FIG. 50. To determine the amount ofcommunication between the ABC and DEFGH groups, the cells in the lowerleft and upper right groups are summed. If this sum is 0, which is thecase in this example, the two groups have no communication between them.These groups form completely separate buses. Cut the pivoted matrixwhere the resulting communication across the cut is 0.

[0466] 2. Within each of the identified groups, find the significantcuts. The communication between the resulting groups should be much lessthan within each group. In FIG. 50, one cut appears in the D-H group andno cuts appear in the A-C group, as shown in FIG. 51. The data transferrate between the GH groups is 22, but the data transfer rate within theother groups is a very large number (##). These clusters can form twobuses with a bridge between them.

[0467] 3. If the communication between clusters or within clusters doesnot involve all blocks, you might need to optimize the clustering. It isonly important to optimize if the latency matrix has very differentrequirements for communication between certain blocks. For example, FIG.51 shows that the GH cluster does not communicate with DE. DE and EFcommunicate but D and F do not. If the latency requirements for DE arevery tight, the designer should therefore split out the DE communicationfrom the rest of the bus. From FIG. 52, we can see the resulting matrix.This example splits E into E and E′ so it appears to be two separateblocks, because separate interfaces will be created on E for the twobuses. If a block has two or more bus interfaces, this technique may beused to make effective use of the separate interfaces.

[0468] If this technique is used on the original example of FIG. 43, theclusters illustrated in FIG. 53 are created, comprising two buses with abridge between them. One bus transfers a significant amount of datawhile the other transfers very little. Another cut between Block 3 andPIO would result in even lower communication between the clusters.However, this is not a significant cut because it leaves only one blockin a cluster, so it is not made.

[0469] 4. When all the cuts are made, the resulting cluster informationis passed on to the next task.

[0470] This clustering technique requires system knowledge to generate abus structure for the chip. The designer must consider data timing andimplementation details such as existing block bus interfaces, additionalprocessor requirements, and the number of masters on the bus. Thesefactors might suggest that deviating from the structure obtained usingthis clustering method creates a bus structure with better performanceor lower gate count than the one obtained by purely following theprocedure. If so, the designer might want to repeat this task to modifythe clustering results.

[0471] Selecting Buses

[0472] Once the designer has defined buses using the clustering method,bus types and performance hierarchy must be selected. Bus hierarchy isthe order of buses that are interconnected from the highest-performancebus down to the lowest. For example, if a design contains a high-speedsystem bus and two lower-speed peripheral buses, the hierarchy is fromthe system bus to the two peripheral buses.

[0473] The bus attributes and sizes from the bus taxonomy referencelibrary are preferably used to define the bus type for each bus. Thelibrary lists a set of bus attributes for each of the available bustypes. To select the appropriate bus, the designer analyzes each blockin the cluster for existing bus interfaces. If there are none or few,the bus type in the bus taxonomy reference that has the most similarattributes is selected. The result of this selection process is adefined set of buses and hierarchy that is used in the next task,specifying the bus design.

[0474] Buses should be selected as follows, checking the parameters inthe bus taxonomy reference library and the interfaces of the blocks inthe design:

[0475] 1. Eliminate buses that do not meet the cluster's bandwidth andlatency requirements;

[0476] 2. If the bus is already defined, use that bus, but otherwise;

[0477] 3. If a processor is present, use the system bus to which italready connects, otherwise;

[0478] 4. Select a bus to which most blocks already connect;

[0479] 5. Use a bus that can handle the endian-ness (a big-endian hasthe 0 bit on the left end of the data unit; a little-endian's is on theright) of most blocks to which it is connected;

[0480] 6. If the loading on the bus is excessive, use multiple buses;

[0481] 7. Separate lower bandwidth devices onto a peripheral bus orbuses;

[0482] 8. Use a peripheral bus with an existing bridge to the selectedsystem bus;

[0483] 9. If there is more than one choice after the selection processis complete, choose the bus type that best meets the OCB attributeslist, since it will have the most tool and model support.

[0484] Calculate the Bus Size

[0485] The bus latency table are used as the starting point for thisstep. Once specific bus configurations are identified using clustering,the information must be translated into a form usable to determine thesize of the buses. In the matrix from the previous task's example, thefirst four entries are clustered in one group and the last two areclustered into a second group.

[0486] Calculating the bus sizes requires determining the bandwidthneeded for the amount of data being transferred and calculatingbandwidth, substituting different bus width values until the targetbandwidth is approached as closely as possible.

[0487] Determine the Target Bandwidth

[0488] Determining the target bandwidth needed for the buses in apattern set requires the following steps:

[0489] 1. Add all the transactions that occur in each cluster in thepivoted data transfer matrix. Continuing with the same example, thereare 62,600 in the large cluster, 100 in the small cluster, and 1,200between the clusters. The matrix in FIG. 55 is therefore created byadding the entries in each of the four groups of FIG. 54.

[0490] 2. Determine the time this pattern set is expected to take. Thefront-end acceptance task provides this information. For this example,the pattern set must be transferred in one millisecond, that is, thefast cluster must transfer 63,800 bytes of data—1,200 bytes to thebridge and 62,600 bytes internal to the bus—in 1 ms. Bandwidth isdefined as the amount of data, in bits, that can be transferred in onesecond. In this example, we can transfer 510 Kbits in 1 ms, and thebandwidth is approximately 510 MHz.

[0491] Calculate the Bus Width

[0492] Bandwidth is comprised of the number of wires in the bus (buswidth) times the clock frequency at which the data is being transferred.

[0493] The calculation is as follows:

(util/clock_cycle)×bus_width=bandwidth

[0494] where:

[0495] util is the minimum bus utilization percentage for the bus typeselected (see FIG. 59);

[0496] clock_cycle is the clock cycle for the design; and

[0497] bus_width is the number of wires in the bus. This value must be apower of 2;

[0498] To calculate, we start at 2¹ for the bus_width and keepsubstituting higher values (2², 2³, . . . ) until the resultingbandwidth value is greater than the target bandwidth. For example, ifthe clock cycle is 20 ns and the bus utilization is 25%, the number ofwires rounded to the nearest power of 2 is 64 bits, where

(25%/20 ns)*26=800 MHz>510 MHz.

[0499] In this example, if one selected a type 4 or 5 bus from the tablein FIG. 59 one would need at least 64 bits in the bus for the fastcluster. Similarly, a 20 ns cycle time would need only 8 bits for theslower cluster.

[0500] The latency information is partially a function of theutilization, since increased utilization of a bus increases latency. Tokeep the example simple, such complexity is not included; it ispartially accounted for in the utilization numbers. In general, however,if one uses the minimum bus utilization numbers for the bandwidthcalculation, the latency tends toward the minimum as well. To accountfor this effect, the designer should select the worst-case (smallest)latency requirement from the cluster.

[0501] The designer can therefore derive the latency of the entiretransaction from the latency matrix used in simulation, but the table ofFIG. 59 shows the bus latency data and transfer values as separatenumbers. FIG. 59 shows a maximum transfer latency of 10 for a type 4bus. The minimum data latency is closer to the number of cycles requiredfor the data alone. The designer therefore needs to calculate what thenet transfer latency is by subtracting the data transfer time from thenumbers in the latency matrix, illustrated below:

data_transfer_time=min_cycles/num_words*avg_trans

[0502] where:

[0503] min_cycles is the minimum number of data latency cycles for thisbus type;

[0504] num_words is the number of words in the bus; and

[0505] avg_trans is the average transaction size: the number of bytes ofdata from the data transfer matrix (FIG. 43) divided by the number oftransactions in the transaction matrix (FIG. 44).

[0506] To compare the latency from the table, the designer must create anew latency matrix that uses the latency values from the simulationmatrix minus the transaction's data latency. In the example above thistable would be as illustrated in FIG. 56. Each element in this matrix iscalculated as follows: [Resulting Latency(x,y)−Min Bus Latency data(type)]*(Data Transfer(x,y)/[Transaction(x,y)*bus size]).

[0507] The smallest number in the system bus cluster is 25. This valuemust be larger than the largest transfer latency for the type of busneeded because of bandwidth. That number is 10 in the table of FIG. 59for transfer latency for bus type 4, so the designer can choose bus type4 or better for the fast cluster.

[0508] Create the Bus Hierarchy

[0509] Once the designer has identified the buses and their loads, thebus performance hierarchy must be identified, comprising determiningwhich are high-speed buses, which are low-speed buses, and what bridgesand arbiters are required. If two buses are connected in the reduced busmatrix (their from/to cells have non-zero values), then we create abridge between them. Using the example in FIG. 54, we create thefollowing bus model from the pivoted data matrix and the reduced busmatrix:

[0510] A system bus (type 4 or 5) of 64 bits connected to:

[0511] Block 1 (RNV)

[0512] Block 2 (RNV)

[0513] Memory (RNV)

[0514] PCI (RNV)

[0515] A bridge (RNV) to a peripheral bus (type 3 or better) of 8 bitsconnected to:

[0516] Block 3 (R/W)

[0517] PIO (Write only)

[0518] Note: The PIO is write-only because there is no data coming fromit. The bridge is read/write because both diagonals between bus 1 and 2are non-zero.

[0519] This map is then passed to the next task, specifying the busdesign.

[0520] Specify the Bus Design

[0521] To specify the bus design, the designer expands the created busesinto a set of interface specifications for the original blocks, a set ofnew blocks, such as bridges and arbiters, and a set of glue logic. Theoriginal and new block specifications are passed to the block designtask. The glue logic, as mini-blocks, are transferred through blockdesign to the chip assembly task. If a bus meets the OCB attributesspecification, it has models for master and slave devices, as well asother bus objects such as arbiters and bridges. Using the map definedselecting buses, the designer then creates the detailed bus structure.

[0522] Detailed Bus Structure

[0523] To create the detailed bus structure, the designer should then:

[0524] 1. Optimize the bus by eliminating all buses with a single loadand a bridge. The load should be placed on the other side of the bridge,since it is slower and more costly in terms of gates to translatebetween the protocol of the system bus and the peripheral bus for onlyone load. While the designer may not be able to entirely eliminate thebridge logic, tristate interface can be eliminated since the bus reducesto a point-to-point communication. Also, 8 bits can be turned into 16without much penalty, since the two erids can be placed together.

[0525] 2. Assign bus master and slaves to the various loads. Thedesigner should start with the bridge. It is a master on the slower sideand a slave on the faster side. All devices on peripheral buses areslave devices. On the system bus, master and slave are defined by whichdevices need to control the bus. Knowledge of the design can help withthis decision. If a processor is connected to the bus, its interface isa master. Otherwise, if there are no obvious masters, the externalinterface, such as the PCI, is a master. The memory interface is almostalways a slave interface. To determine which block requires a masterinterface, the designer should refer to the interconnect requirementsfor the bus.

[0526] 3. If a processor or other block is connected to a bus that alsohas a memory interface, and the block specifically requires it, thedesigner should include one or more direct memory access (DMA) deviceson the bus. These devices act as bus masters.

[0527] 4. Finally, if two or more devices on a bus are bus masters, addan arbiter.

[0528] Detailed Bus Design

[0529] When the bus structure has been defined, the block bus interfaceis checked. If blocks already have bus interfaces, the interfaces mustbe in a soft, firm, or parameterized form for tailoring to the bus. Ifthis is the case, the existing bus interface logic should be used,otherwise the models provided with the bus are acceptable. If there is adifferent bus interface on the blocks, it should be eliminated ifpossible.

[0530] The bus logic should be modified to interface with the bus asfollows:

[0531] 1. Assign address spaces for each of the interfaces. The addressspace is usually designed to match the upper bits of the transactionaddress to determine if this block is being addressed. Also, one shouldensure that each block has sufficient address space for the internalstorage or operational codes used in the block.

[0532] 2. Eliminate write or read buffers if only one function is used.Most existing bus interfaces are designed to both read and write. Thedesigner can significantly reduce the logic if only one of thesefunctions is needed. For example, if the bus takes more than one clockcycle, read and write data are usually buffered separately. If only onefunction is needed, the designer can eliminate half the register bits.

[0533] 3. Expand or contract the design to meet the defined bus size.

[0534] Most bus interfaces are designed for the standard 32- or 64-bitbus, but other alternatives are available. If the designer needs anon-standard bus interface, he or she must modify the logic to eliminateor add registers and signal lines. Similarly, the address is usually thesame size as the data, but this might not be the case. For busses thatinterleave the address and data onto the same bus signals, a mismatch indata and address size only eliminates the upper-order address decode ordata register logic, not the signals.

[0535] 4. Add buffers to the bridges if necessary. Such modificationsshould be made for both sides of the bridge as in Step 3.

[0536] 5. Modify the bridge size mapping between the buses. For aread/write interface, bridges need at least one register for eachfunction, equal to the larger of the buses on both sides. In addition tothe data buffer for each function, bursts of data can be transferredmore efficiently if the data is accepted by the bridge before beingtransferred to the next bus, using, for example, the bridge illustratedin FIG. 57. This might require a FIFO for each function to store a burstand forward it to the next bus, as illustrated in the bridge of FIG. 58.

[0537] 6. Define the priority of the bus masters and the type ofarbitration. If there is more than one master on a bus, there must besome kind of arbitration between the masters. There are many types ofarbitration, ranging from a strict ordered priority to round-robinarbitration. If the masters both handle the same amount of data with asimilar number of transactions and required latency, they should haveequal priority. On the other hand, if there is a clear ranking in theimportance of the masters, with an equivalent order in the amount ofdata, transactions, and latency, arbitration should be serialized,putting the most critical master first.

[0538] 7. Create and connect the arbiter based on the definitions inStep 5. Arbitration schemes can be distributed or centralized, dependingon the bus. Arbitration logic should be as distributed as possible, toenabled it to be distributed into the blocks with the glue logic.

[0539] 8. Map the bus to the interface logic as required by the device'sendian-ness. Most buses are little-endian, but some devices arebig-endian. When there is a mismatch between the end types, the designermust decide how to swap the bytes of data from the bus. This decision isgenerally context-dependent. If all transactions to and from the bus areof the same type of data, the designer may use fixed byte-swapping,otherwise the bus masters must do the swapping.

[0540] 9. Tailor the DMA devices to the bus. Direct memory accessdevices are controllers that transfer data from one block to another.They should be modified to the size of the address bus as one would anyother device.

[0541] 10. Add testability ports and interfaces if necessary. The lowestlevel of test is the ability to test the bus itself. The standard chiptest logic can also use the bus. These test features might requireadditional signals to differentiate test from the normal operation mode.

[0542] 11. Add initialization parameters if necessary. Some buses suchas PCI have configuration registers. These registers might be hardcodedfor configurations that do not change.

[0543] 12. Add optional bus capabilities if required by the devices onthe bus. Some buses have advanced capabilities such as threads, splittransactions, and error retry, which may not need to be implemented ifthe devices connected to the bus do not need them. Some of theadditional capabilities, such as DMA devices, non-contiguous bursttransfers, and error recovery control, might require more signals thanare defined in the standard bus. These signals should be added to thebus if necessary.

[0544] When these modifications are complete, the bus interface logic isconnected to the resulting interface of the block.

[0545] Bus Taxonomy Reference

[0546] The bus taxonomy reference is a library that lists the busattributes and their relationship to bandwidth, latency, and datadirection for the buses that are available in a cell library. Thetaxonomy library is a relatively fixed collection of information. Theperson in charge of this library might need to update the bus attributeswhen a new bus becomes available.

[0547] Bus Type Reference

[0548] Bus types can be categorized by latency and bandwidthutilization. Pure bandwidth is a function of the number of wires in thebus times the clock frequency at which the data is being transferred,but bandwidth utilization is a function of architecture.

[0549]FIG. 59 shows a list of specific bus attributes from lowestbandwidth utilization and longest latency to the highest bandwidthutilization and shortest latency. Typically the cost in logic and wiresis smallest with the first and largest with the last. Each bus in thelibrary must have a bus type assigned from this table. Each bus type canhave a range of latency in cycles and bus bandwidth in utilizationpercentage. Each bus might have a different clock cycle time and size,so the utilization percentage is the effective throughput over theproduct of the cycle time times the size of the bus. A bus utilizationvalue of 100% means that every cycle is fully utilized. The Data Latencycolumn gives the number of cycles it takes for a bus to transfer a wordof data. The Transfer Latency column is the average number of cycles ittakes to begin a bus transaction. The table in FIG. 59 gives a roughestimate of the bus utilization and latency values. A designer's groupcan specify values based on experience and the type of its designs.

[0550] Bus Taxonomy Reference

[0551] Over a number of projects, a design group accumulates a libraryof buses. Each bus contains a set of information that includes the typeof bus from the reference library noted in FIG. 41, and the list of busattributes from the VSI OCB Attributes Specification and the BusTaxonomy Reference found in “Block-Based Design MethodologyDocumentation” Version 1.2, May 21, 1999 (the entirety of which isincorporated herein by reference), at section B.2, pages B-5 to B-10.This information should be used as described for determining which busto use.

[0552] Design for Test

[0553] As described in the background, ease of testing is among the mostimportant attributes of an SOC design. Thus, design for test (“DFT”) hasbecome the standard. For a given customer specification, the DFTknowledge base derived using the method and system of the presentinvention can be searched and extracted to present the customer with aQuestion & Answer (Q&A) form. Through this device, the test objectivescan be negotiated and test issues resolved in the Statement Of Work(SOW) negotiated during front end acceptance.

[0554] The test planning phase is followed by test budgeting, testscheduling and test management, resulting in a set of specifications anda test plan to further break test development into separate, independentsubtasks for a clearly defined goal with a set of known resources andprocedures.

[0555] Each test block is concurrently developed according to aprescribed recipe, which can be tested with the best availabletechniques.

[0556] Once the test blocks are readied for test integration, they canbe mapped to the unconstrained SOC boundary where no I/O restriction isapplied, thereby allowing each layer to become a “test-readied” templatefor the unconstrained SOC to be transformed into a design block. Theunconstrained SOC is then constrained to a specific I/O packaging withadditional I/O level test. This enables a test scheduling process totake place and fulfill the SOC level test objective.

[0557] Making a DFT Test Plan

[0558] After acquisition of the customer's plan during FEA, theinventive test plan development scheme of the present inventionpreferably begins with an assessment of each block to see if it istest-mergeable (whether the test may be performed simultaneously on aplurality of blocks). Next, the designer determines how “testable” eachof the non-mergeable blocks is. Third, a chip-level test specificationincluding test types such as JTAG boundary scan, DC tests, and PLL testsare developed. Finally, test fault coverages are specified fortest-mergeable blocks at the overall chip level, for non-mergeableblocks at the block level, and for interconnect. The results of thisfour-pronged initial analysis provide the DFT objectives for the overallsystem design of the present invention.

[0559] Using DFT Rules

[0560] DFT architectural rules, which are specific, test-relatedconstraints, are used to maintain consistent test development flow andcohesive test data management. These rules guide the application of testattributes to each non-mergeable block for placement in a virtual socketat the top level, guide the execution of trade-offs to get the simplestand most adaptive test strategy, shape the creation of a top-level testspecification for the design, and enable the derivation of a test planto detail the test implementation process.

[0561] DFT Glossary

[0562] The listed DFT terms, as used and claimed herein, have thefollowing definitions: Authorization A conversion process that makes itpossible to integrate a pre-designed block. BIST Built-in self test BSRBoundary scan register(s) CAP Chip access port CTAP Core test accessport DAP Design access port DFT Design for test Fault coverage Stuck-atfault coverage of a test ICTAP Integrated circuit test access port IPIntellectual property JTAG Joint Test Action Group (iEEE-i 149.1) Legacyblock A predesigned gate-level block that cannot be modified orreverse-engineered for reusability without risking unknown consequencesMergeable The test requirements for a mergeable component can becombined with those of one or more other components, so they can betested as a unit, saving test time and costs MISIR Multiple inputsignature generator Mux Multiplexer Non-mergeable Cannot be merged withother blocks for parallel testing PRPG Pseudo-random pattern generatorSAP Socket access port Socketization An adaptation process to specifyand add a test collar to a pre-designed block that permits testingwithin a design TAP Test access port TBA Test bus architecture Testcollar A collection of test ports and logic surrounding a predesignedblock that provide test access and control Test-mergeable A block thatcan be merged with at least one other block, the two or more blocksbeing tested by a single test protocol Timeset Cyclized tester timeformats: RZ (return to zero), NRZ (nonreturn to zero), RTO (return toone), DNRZ (delayed nonreturn to zero) UDL User-defined logic VC Virtualcomponent Virtual socket A placeholder for a predesigned block thatincludes its test interface VSIA Virtual Socket Interface Alliance

[0563] Making a Test Plan

[0564] The process of creating an overall DFT test plan begins with thetest designer receiving, from the FEA-generated input, test techniquesfor each block, expected test vector specifications, test timerequirements for production, and special parametric or analog testssupplied by the I/O and analog/mixed-signal (“AMS”) requirements module(xref). Creating a complete DFT plan therefore comprises effectiveorganization and use of this data.

[0565] Test Requirements for Non-Mergeable Blocks

[0566] A chip-level test requirement includes the non-mergeable blocktest requirements, which, in turn, comprise four components: testmodels, test control logic such as dedicated test ports and test modes,test isolation logic such as safe-outs, and test validation componentssuch as test benches and test vectors. When non-mergeable blocks aredelivered to the customer, they specify: test access and control data(such as test modes, activation, and deactivation), test protocols, testdata, tester format, and test application/setup time.

[0567] Test Requirements for Mergeable Blocks

[0568] The chip-level test requirement also contains test informationfor all test-mergeable blocks, which, in turn, comprise test method,test control logic, interconnect implementation mechanism, and testvalidation components.

[0569] Chip-Level Test Requirements

[0570] The chip-level test requirement also includes DC testrequirements, AC test requirements, Iddq test requirements such as powerdistribution, and analog test requirements,

[0571] Chip-level test controller

[0572] Test controls at the chip level can be the test interface, JTAG,PRPG, and MISR.

[0573] Component Attributes Matrix

[0574] The designer may use a matrix to plan the test developmentenvironment for components in the BBD design. This matrix documentsissues, recommends or evaluates possible resolutions, and notes whereadditional information is required. The matrix also identifies areas ofconflict where there are difficulties and incompatibilities in the testdesign.

[0575] Using DFT Rules

[0576] Once the designer has filtered and classified the chip-level testrequirements by using the matrix, he or she can process theserequirements with a set of DFT architectural rules. Using architecturalrules allows for the establishment of common access, test control, testclocks, and asynchronous attributes, and trade-offs based on availableDFT architectures to enable the creation of a unique hybridized DFTarchitecture for the chip being designed.

[0577] Adaptability is a key feature of the BBD DFT strategy of thepresent invention. To ensure proper test integration, the designerassigns a virtual socket to each non-mergeable block based on theconstraints and test information received at the end of front-endacceptance. The DFT architecture completes the specification byintegrating these virtual sockets into the rest of the chip-level testrequirements. Each virtual socket has a socket access port (SAP) mappedto the chip access port (CAP) to effect such a transformation of thetest data.

[0578] Before the designer can make a test plan and start preparing thedesign for test, he or she must check the group's DFT architecture rulesfor consistency and cohesion.

[0579] Consistency

[0580] Consistency is the degree to which test development coverage foreach component is complete, in four operating modes: normal, test,isolation, and boundary (co-test). The designer may use a checklist foreach component to ensure that its model, controller design, isolation,and test validation values are consistent between each block and thechip-level description.

[0581] For example, in a design with three non-mergeable blocks, A, B,and C, the test controller design can test block A only if blocks B andC are isolated. The test controller specification must specificallyenable a block A test access only when both B and C are isolated. Ifblock B and block C are to be tested concurrently, the test controllerspecification must enable test access to both blocks with a testvalidation scheme that synchronizes their test data in a singlesimulation environment.

[0582] For this example, the table of FIG. 60 illustrates an exemplaryblock A consistency check.

[0583] Cohesion

[0584] Cohesion is the degree to which test methods in a flow arerelated to one another. There are five closely-related test methodparameters;

[0585] each can modify the others. For example, the test access methoddefines the activation condition of a test protocol, the test protocoldefines how test data is sequenced, and test data is broken down to aset of patterns having a specific tester timeset. And since test accessto an embedded block is sensitive to chip I/O restrictions andcontroller design, the cohesion of these parameters requires a uniqueverification style to maintain test data integrity. The five test methodparameters are therefore test access, test protocol, test data, testertimeset, and test time.

[0586] Architecture Rules

[0587]FIG. 61 illustrates the top-level hierarchy of a chip from the DFTperspective. Before the designer begins the DFT process, the designershould visualize the chip as shown in FIG. 61, rather than as acollection of functional blocks. FIG. 62 shows the design made up offunctional blocks, with the SAPs and a DAP where non-mergeable blocksare socketed.

[0588] In practice, functional blocks in the design can be described inbehavioral, RTL, gate, or mixed-level HDL. The HDL files are organizedin a directory structure. The preferred way to organize test files is tocreate a directory hierarchy as described in the following architecturerules, then put links in the test directories to the data files in thedesign hierarchy. In this way, the chip can be built with differentconfigurations using HDL directives.

[0589] Because the chip-level DFT architecture has only a single level,all attributes are at the top level. It is therefore intended that thedesigner should use the following architectural rules in accordance withthe method of the present invention to put attributes in extractablecomment form in the top-level design file:

[0590] 1. Describe the DFT architecture hierarchically.

[0591] 2. Create a single chip access port (CAP) at the highest level ofhierarchy. The CAP specification should preferably:

[0592] a. Map all test control and test data pins to the package-levelpin to consistently maintain design and test data.

[0593] b. Separate the test control pins from the test data pins.

[0594] c. Set the test control pin attribute to either dedicated orselectable:

[0595] i. dedicated if it should preferably be exclusively deactivatedin normal mode; a dedicated pin cannot be shared with a functional pin.

[0596] ii. selectable if it can be set to a test constant—a logicalvalue—throughout a test; a selectable pin can be shared with afunctional pin.

[0597] d. Set the test data pin attribute to:

[0598] test_clock if it is used as a clock during test; a test_clock pincan only be shared with an external functional clock pin.

[0599] test_async if it is used asynchronously during test for reset; atest_async pin can be dedicated or shared if it does not cause anyconflicts with other tests, test modes, or isolation modes.

[0600] test_group(i) where (i) is the test_clock with which thetest_group pin is synchronized during a test.

[0601] e. Describe the following for each test mode:

[0602] i. The test setup needed to gain access to the device under testif it requires an accessing sequence. Describe the protocol, such asJTAG instruction, test clock, or test reset.

[0603] ii. The test execution needed to perform the actual test.Describe the test sequence in phases down to the task level, theiteration counts, the cycle time, the test length, and the test results.

[0604] iii. The test postprocessing needed to close out the test and putthe chip back in the default condition (normal mode).

[0605] 3. Create a CAP controller specification that describes the testsetup and test processing sequences for each test mode. Thespecification should preferably be implementable (synthesizable) andverifiable (via test benches and test sequences).

[0606] 4. The designer may optionally specify a set of staging latchesto fold the internal test data bus into the available test data pins.The staging action should preferably not alter the subsequent testresult. The staging should preferably be

[0607] a. Free from state-altering, time-sensitive signals. Usetest_async signals or follow the persistent order of occurrence relativeto the test_clock to resolve it.

[0608] b. If it is not free from state-altering, time-sensitive signals,it should have extra test pins. This rule should preferably be usedjudiciously to avoid test packaging problems.

[0609] 5. The designer may optionally specify a test data signatureanalysis capability such as MISR to compress the test data, whichminimizes the physical I/O constraint. The signature analysis shouldpreferably be deterministic for each cycle of operation and shouldpreferably:

[0610] a. be free from X-value propagation by avoiding it at the MISRinputs.

[0611] b. if step a. fails, suppress the affected MISR cycle. This ruleshould be followed judiciously to avoid the loss of fault coverage.

[0612] 6. The designer may optionally create a set of other testmechanisms at the chip periphery to perform the following special tests:DC and AC parametric tests such as boundary scan tests; frequency testssuch as PLL tests; and mixed-signal tests such as ADO and DAC tests. Thecontrol pins for these tests should preferably be included in the tableof all test control pins. The designer might also want to include themin the CAP controller specification to avoid conflicting interactions.

[0613] 7. Specify a single device access port (DAP) at the next level ofhierarchy, the level without I/Os or I/O-related cells, unrestricted tothe physical I/O.

[0614] 8. The DAP should preferably be a hybridized test port that canbe formed by concatenating, merging, resizing, and multiplexing genericports, such as TAP-based ports.

[0615] 9. The designer should preferably be able to configure the DAPdirectly from the CAP controller. Partition each configuration into testcontrol, test data, or test isolation ports. In each configuration:

[0616] a. Set the test control port attribute to

[0617] test_con f(k) if it should preferably be used to set the targetedconfiguration k.

[0618] test_select if it can be set to a test constant.

[0619] b. Set the test data port attribute to

[0620] test_clock if it Is used as a clock during test.

[0621] test_async if it is used asynchronously during test.

[0622] test_group(i) where (I) indicates the test clock to which theports are synchronized.

[0623] test_direction if it is used to indicate the test data direction.The test direction can only be a 1 or 0 value.

[0624] c. Set the test isolation port attribute to safe_state if itshould preferably be isolated during test with a safe state logic valueof 0, 1, or Z, and to dont_care if it can be set to a non-floating logicvalue of 0 or 1.

[0625] 10. Specify the interconnection of the CAP, the CAP controller,the staging latches, the MISR, the DAP, and the other test mechanisms

[0626] 11. Specify the CAP controller, the staging latches, the MISR,the design body, and the other test mechanisms in a dedicated section.

[0627] 12. Specify detail on the DAP the sockets, the UDL, and the testinterconnect for the design body architecture only.

[0628] 13. The design body architecture should preferably be describedhierarchically.

[0629] 14. There should preferably be multiple SAPs at the next level ofhierarchy, the socket level.

[0630] 15. Each SAP should preferably be a recursive image of the DAPwith one or many applicable configurations available to the DAP. Allconfigurations of the SAP should preferably be supported by the DAR.

[0631] Socketization Rules

[0632] Once a non-mergeable block or VC is placed in a design, its I/Oports are no longer accessible from the chip I/O. Its test data, whichis created at the I/O ports, is no longer usable either.

[0633] In general, recreating test data at the chip level is difficultand unpredictable because design block test values must propagatethrough other logic blocks. The preferred approach, therefore, is to addaccessibility to the design block itself by creating a virtual socketfor the design block. The virtual socket includes test access,isolation, and boundary test functionalities accessible from the chipI/O.

[0634] The designer can use the virtual socket as a placeholder for thedesign block in the design, or can also use the socket to put testconstraints on the design block itself. A design block is socketizedwhen constraints are mapped to it in a design using I/O mapping andrestrictions. The constraints are design-sensitive and conditional, butthey let the designer divide each design block socketization taskcohesively while keeping track of the design blocks during designintegration.

[0635] The socketized design block might need extra I/O ports and alogic or test collar to match the chip-level test constraints whilemaintaining the functional interface. Because the interface timing mightbe changed slightly, it is best to write the test collar in RTL code, tobe characterized or rebudgeted in synthesis for each socketized designblock. Adding the test collar at the gate level after synthesizing thewhole design might cause timing problems.

[0636] The design block socketization rules are as follows:

[0637] 1. The socket can be described hierarchically but the top levelshould preferably contain all the test attributes.

[0638] 2. There can be only one SAP per socket.

[0639] 3. The SAP Is the only reference for test information about howto isolate, test, diagnose, and debug every element in the socket.

[0640] 4. Each SAP should preferably be constructed or synthesizedaccording to the higher level specification.

[0641] 5. The designer should preferably be able to verify, at thehigher level of construction and context, that each SAP can activate anddeactivate normal, test, isolation, and boundary modes. This means thedesigner should verify the external test information structure of thesocket.

[0642] a. The external test information structure should preferablyconform to the standardized description language specified in the VSIAcompliance rules.

[0643] b. If a standardized description language is not available, thetest information structure should conform to the chip-level design testattributes at the virtual socket.

[0644] 6. Each SAP should preferably be validated at the socket levelwith the reformatted test data to ensure that it properly performs thetest setup, test execution, and test postprocessing sequences. Thismeans the designer should verify the internal test information structureof the socket.

[0645] a. The internal test information structure should preferablyinclude all design block test models, all functional blocks, and allother logic bounded by the socket.

[0646] b. The internal test information structure should preferably beco-simulated and interoperable with the chip-level simulationenvironment.

[0647] 7. In normal mode, all test logic associated with the SAP shouldpreferably be deactivated simultaneously and directly, not sequentially,from the SAP interface. Normal mode should be activated by a single testcontrol port.

[0648] 8. In isolation (rest) mode, all test logic associated with theSAP should be deactivated and assigned to safe-state values withoutintermediate conflicts. No functional states may be implied in theisolation sequence.

[0649] 9. In test mode, all test logic associated with the SAP shouldpreferably be enabled by a single activating sequence, then optionallyby a configuring sequence, before beginning a test sequence. To minimizetest time, successive test sequences of the same configuration should bebundled.

[0650] 10. All of the socket's peripheral logic should be testable inboundary (co-test) mode, including the test logic associated with theSAP.

[0651] Designing a Top-Level Test Logic Specification

[0652] When the designer designs a top-level test logic specification tomeet coverage and time requirements, he or she will need to maketradeoffs that increase the parallel nature of the test logic. The majordecision is how serial or parallel to make the individual block tests.

[0653] The test constraints are used for each virtual socket with thesocketization rules to establish test requirements for constructing thetest collar. From the test access perspective, the SAP is complete andadequate for test integration purposes. To avoid design changes that cancause design and test conflicts, the SAP should not share or usefunctional elements of the block. This separation makes even more sensewhen different block types—soft, firm, or hard blocks—are utilized,making it possible to avoid unpredictability during test integration.

[0654] In general, each architecture aims at a unique set of solutionsor a specific set of tools, and targets a specific range of testapplications. Many architectures originate in specific designenvironments that span almost every role of a design. Therefore, adevelopment flow is needed that does the following:

[0655] 1. Characterizes and categorizes test problems in the designcontext;

[0656] 2. Addresses the trade-offs for each architecture;

[0657] 3. Provides additional alterations for each targeted design.

[0658] 4. Until the advent of the present invention, BBD test problemswere evident in the following areas:

[0659] Test data reusability

[0660] Test socket design and socket information

[0661] UDL and chip-level interconnect testing

[0662] Test packaging

[0663] Test validation

[0664] Test protocols

[0665] Diagnostics and debugging

[0666] These issues are related to the assumptions made during BBDdesign planning. However, the design plan requires many specificprocesses to package a design block with reusable test data, such as:creating the BBD design for test, customizing the design block testinterface, designing and validating the test access and controlmechanism, and packaging the test with the chip I/O and within the testbudget.

[0667] DFT Taxonomy

[0668] DFT architectures are classified by their test methods, theirtest interfaces, and the types of blocks with which they can be used.There are four different generic DFT architectures, but they rarely havesimilar test interfaces. For example, most chips have embedded RAM thatuses a memory BIST interface while the rest of the chip might use a scanmethod. The table in FIG. 63 lists the typical choices in a designscenario.

[0669] Procedure for creating a Top-Level DFT Architecture

[0670] The flowchart of FIG. 64 illustrates the procedure used to createthe top-level architecture specification and specify chip-level teststructures. The DFT plan should preferably specify the block-level testlogic for every block on the chip. Blocks with test logic should receiveinterfaces to the top level. Blocks without test logic should receivetest logic requirements. Transfer both of these design requirements tothe block design task, preferably creating both the top-level test logicand the access mechanism.

[0671] The flowchart in FIG. 65 illustrates the socketization procedureused to create the block test logic specification. For each socket inthe design, specify the test collar for each design block to conformwith the DFT architecture as illustrated.

[0672] Creating a Test Generation Mechanism

[0673] The BBD strategy for test generation can comprise manual vectors,ATPG, or mixed. The translation and concatenation mechanisms should bedefined to match the top-level test logic and the individual blocks'test mechanisms. In BBD, test development comprises two independentprocesses.

[0674] 1. Block-level test development for each virtual socket. In mostcases, this process consists of the following tasks:

[0675] a. SAP declaration: Add the SAP to the behavioral model interfaceand re-instantiate the block with its virtual socket.

[0676] i. Test logic insertion: Add test access, isolation, interconnecttest, and test control logic to form the test collar around the targetedblock. For best results, describe the test collar in synthesizable RTLformat.

[0677] ii. Test data transformation: Expand and map test data into SAPports. One should modify the block-level test bench to accept the newtest data format. To streamline the test flow, one might alter thetester timing on some blocks to minimize test setup time per socket andconcurrently run multiple block tests.

[0678] iii. Test verification: Modify the block-level test bench toverify the test logic. Verify the target block with a subset of thecomplete block-level test vector set to ensure test data integritybefore and after the previous steps

[0679] 2. Chip-level test development for all test-mergeable blocks andchip-level tests such as DC tests and analog tests. This processcomprises the following tasks:

[0680] a. Test logic insertion: Add the test controller, dedicated testpins, DC test logic, analog test logic, and, it necessary, clock muxesand test clocks for all tests. This task also involves scan insertionfor test mergeable blocks and UDL if necessary.

[0681] b. Test generation: Use ATPG tools to generate test data for thetest-mergeable blocks and UDL, or capture cyclic functional test data.It is important to meet fault coverage objectives with the targetedmanufacturing test data.

[0682] c. Test verification: Modify the chip-level test bench to verifythe test controller and perform DC tests, analog tests, tests for allvirtual socket in the design, and the UDL test. These tests might needpre- and post-test sequences such as JTAG requires.

[0683] d. Test data formatting: Take the simulation results and put themin a test data description language such as WGL.

[0684] We turn next to the application of DFT at the block level in aBBD DFT methodology context. The final product of an intellectualproperty core or design block is a “test-readied” block with astandardized or generic test interface and a test data set that can bereused at the chip level. The design block socketization scheme isemployed to transform a design block into an integral part of the chiplevel tests while reusing most of the test procedure and apparatusgenerated during the designing of each block. The inventive BBD DFTmix-and-match strategy provides a flexible approach to integrate avariety of pre-designed blocks with different test methods and testinterfaces by sorting out non-mergeable blocks in contrasting to themost popular scan based test methodology. The reason to make scan designmethodology the basis for test mergeable selection is simply the ease ofautomation purpose.

[0685] The block design plan involved in many specific processes topackage a design block with re-usable test data is based on astandardized or customized design block test interface, taking intoaccount certain assumption about accessibility of block I/Os. However,once embedded, the block I/Os can be placed in different contexts andpotentially become inaccessible. To ensure the ease of integration, thetest interface should be separate from the functional interface toprovide some orthogonalities from the chip design perspective. In BBD,one attempts to mix and match the design block interfaces and unify themat the chip level (as illustrated in FIG. 68). Therefore, theflexibility and modifiability of the test interface should be providedto design and validate the test access and control mechanism, and topackage the test with the chip I/O and within the block level testbudget. As understood by one skilled in the art to which the presentinvention pertains, though possible, the use of an On Chip Bus (OCB) aspart of the test bus is contemplated by the present invention but beyondthe scope of this description.

[0686] Non Mergeable Blocks

[0687] DFT logic and test vector verification functions let the designerrun shorter, production ready tests earlier in the production cycle. DFTscan paths provide access to chip and system states that are otherwiseunavailable. Memory BIST uses algorithmic test vectors to coverdifferent embedded memory fault classes. Logic BIST takes advantage ofrandom testable structure of scan based design to reduce test access andtest data bottlenecks. However, each predesigned block may becomenon-mergeable for a number of reasons. In general, non-mergeable blocksare:

[0688] Synthesizable RTL soft blocks that may not be compatible withcommon test methods due to lack of internal test accessibility (e.g.gated-clock, latch-based, data paths), or lack of fault coverage (e.g.asynchronous).

[0689] Gate-level soft blocks that may not be compatible with commontest methods such as scan methodologies (i.e. synchronous), scan styles(e.g. mux-scan, clock-scan, LSSD).

[0690] Compiled blocks that are generally array-based. For example,embedded RAMs, ROMs, DRAM, FLASH, etc. do not have the same fault modelsas combinational logic. These blocks require large algorithmic testpatterns.

[0691] Hard blocks that are created with a specific test method but doesnot have the infrastructure available for test integration. Generally,these blocks should preferably be delivered with a specific block leveltest data set with or without a specific test interface.

[0692] Legacy blocks that are created with or without a specific testmethod but does have the infrastructure for integration. Generally,these block may not be modified to avoid unknown consequences.

[0693] Test Collars

[0694] The socketized design block can be modeled by creating a newmodule that describes the socket with the SAP specification,instantiating the original design block, and inserting test logicbetween them, as illustrated in the flowchart of FIG. 66. The socketizeddesign block first restores the design block functional interface, addtest access, test isolation, boundary test structures then provide thebasic test interface (e.g. TAR scan, BSR, or direct-muxes) as definedduring the chip planning. The result is the SAP with test attributesadded as comments for each associated test I/O port. Each non-mergeableblock will be wrapped by a test collar to add test access, isolation,and interconnect test facilities for performing test setup, testexecution, and test post processing on a block by block basis. Theoutput is a socketized design block including:

[0695] 1. test access and control (e.g. test modes, activation, anddeactivation)

[0696] 2. test protocol (e.g. functional, mux-scan, BIST, diagnostics);

[0697] 3. test data (e.g. test language, vector size, fault coverage);

[0698] 4. tester format (e.g. tester specification, timesets, testspeed);

[0699] 5. test application time (e.g. no test setup time);

[0700] Adding Testability

[0701] For each non-mergeable block which does not come with re-usabletest data, the design planning phase can specify the test interface,test method, test data format, expected fault coverage, and test budgetby inserting test structures and estimate the overall area and timingcost. This estimate becomes the constraint for adding testability toeach block.

[0702] Synthesizable RTL Soft Blocks

[0703] If the pre-designed block is a synthesizable soft block whichdoes not compatible with scan based test application then fault coveragecould be a problem. For example, scan design rule check can be done atthe RTL or gate level to screen out scan violations. Since scan chain ortest points can not be easily inserted into the model, sequential ATPGcan be used in conjunction with functional test vectors, as illustratedin the flowchart of FIG. 67. The fault coverage for this type of designis difficult to predict and fault simulation should preferably be usedto establish the re-usability criteria of such block during the planningphase. The TBA based test collar is the best test interface but the BSRbased test collar could be considered if test budget for the block isallowed.

[0704] Verification

[0705] Moving now from DFT to design verification, the primary objectiveof the verification method and system of the present invention is toensure that a completed design (at final tape out) meets the customer'sfunctional requirements as specified in the Functional Specification andChip Test Bench, supplied as part of front-end acceptance. A secondaryobjective is to achieve the primary objective in the minimum timepossible.

[0706] It is especially essential to the proper function of the presentinvention, as it is to any design test scheme, that thecustomer-supplied Chip Test Bench form a complete test of the customer'srequested functionality. This assumption is preferably emphasized duringfront-end acceptance. The BBD design flow will thereby incorporategrading of the Chip Test Bench while running on the FunctionalSpecification model, thereby providing a measure of the Chip Test Bench.

[0707] The inventive approach is to utilize both the FunctionalSpecification and the Chip Test Bench in an integrated manner, to insurethat the two are consistent. Subsequently, as detail is added andrefined through chip planning, chip assembly and block design, thedesign is re-verified via the Chip Test Bench to ensure thatfunctionality remains consistent with the original FunctionalSpecification. Verification of progressively more-detailed views may beperformed at the complete chip level or at the individual block levelwith distinct Block Test Benches extracted from the Chip Test Bench, asdescribed below.

[0708] Experience reveals that bus logic and the interaction of variousblocks connected along the same bus can take significant time toresolve, causing iterative re-designs if not addressed early andcontinuously in the design process. For this reason, particularattention is given to validation of the bus functionality early in thedesign cycle. The bus and associated logic is therefore identified at anearly stage and verified, independent of the rest of the design, usingBus Compliance Test Benches, as described below. However, it should benoted that the preferred verification flow of the present invention isflexible enough to handle a wide variety of designs with rapidturnaround. For example, if a design uses simple busses or the designerhas significant experience with the blocks attached to the bus, thensome or all of the bus compliance testing may be deferred. Similarly, ifsome or all of the blocks are either simple or reused from a priordesign, then a portion of the individual block verification may beskipped, and verification deferred until the chip level verificationstage is reached.

[0709] The detailed flow to be followed for a particular design shouldbe established as part of the FEA process. FIGS. 12-15 provide ageneralized flow of the tasks to be performed during functionalverification according to the present invention. These figures will bedescribed in detail, with cross-reference make to chip test bench FIGS.69-73. It should noted that in FIGS. 12-15, a large arrow signifies taskflow, a smaller arrow signifies task inputs, and a dashed arrowsignifies an optional bypass path.

[0710] Referring to FIG. 12, after completion of FEA, as describedabove, the method of the present invention continues with chip testbench verification step 8210, wherein the chip-level functional model isexercised with the chip test bench 8310 in FIG. 69. Both the model andthe test bench are customer-supplied, the purpose of verification beingto ensure that the test bench and functional model are consistent. Themodel will preferably be in Verilog, VHDL or executable C code, althoughany compatible language will suffice. Chip test bench 8310 will be in afile compatible with the model. Any miss-matches between the model andthe test bench will be fed back to the customer and either the model orthe test bench will be modified to achieve internal consistency.

[0711] Next, the chip test bench is graded while running on thefunctional model. Such grading provides a “goodness” measure, orcoverage metric, of the test bench by measuring one or more of thefollowing attributes: statement coverage, toggle coverage, FSM arccoverage, visited state coverage, pair arc coverage, path/branchcoverage and/or expression coverage. This coverage metric is then fedback to the customer. The coverage metric may highlight areas of thedesign that appear to be poorly tested, as where a design isinadequately tested or the design includes redundant functionality. Ineither case the customer may chose to modify the test bench or the modelto improve the coverage metric, thereby resetting the project start timefor the BBD design methodology herein described.

[0712] Once the chip test bench is certified consistent with thefunctional model, a new view 8312 (in FIG. 69) of the chip is created atstep 8212 (of FIG. 12) by combining the block functional models for eachof the blocks with the defined glue logic between these blocks. Theblock functional models 8312 are either customer supplied or created viaa “dipping” process during FEA, as described above. A glue logic modelis also specified during chip planning, as described above.

[0713] Referring again to FIG. 12, chip level structural verificationstep 8214 comprises simulating the block functional model of the chipwith the chip test bench. Any discrepancies are resolved by modifyingone or more of the block functional models 8312 or the glue logic model,and rerunning the simulation. This step ensures that the blockfunctional models are consistent with the chip functional model.

[0714] Turning next to FIGS. 13 and 14, the objective of the busverification flow is to ensure that the bus logic within the chipoperates correctly and that interactions between the different buselements will not cause bus protocol errors. Thus, compliance vectorsare created for the bus design. These vectors may be based on compliancetest suites supplied by the customer or block design supplier. Thevectors will have to be manipulated to correspond to the specific bustopology of the design. Where compliance vectors have not been provided,they will have to be written by the design team, preferably in such amanner that they exercise the interactions of the various blocksattached to the bus, exercise all boundary conditions, and verify thatbus errors are correctly handled.

[0715] Step 8218 in FIG. 13 provides for the verification of busfunctionality. The bus compliance vectors are simulated against thecycle-accurate model of the bus supplied from the chip planning stagediscussed above. Any errors must be resolved by either modifying thecompliance vector set (not shown) or by modifying one or more of the buslogic elements 8512 shown in FIG. 70. This step is repeated until thecompliance test suite executes successfully on the bus logic model.

[0716] Referring next to FIG. 14, bus block model and test benchcreation steps 8610 through 8614 are illustrated. The objective of bothbus block model creation step 8610 and test bench generation extractionstep 8612, as well as bus block model verification step 8614, is tocreate a high level behavioral model and associated test bench for eachof the blocks within the design. These are passed to the block designersand define the target functionality for each of the blocks.

[0717] Creating bus block model 8510 in FIG. 70 for each block comprisescombining the functionally correct, cycle-approximate block functionalmodel 8312 with a cycle-accurate bus logic model for that block. The buslogic is extracted from the bus glue logic model supplied from chipplanning and verified above. Some modification of the Bus FunctionalModels may be required to get the interfaces to “align.”

[0718] The bus block models are then verified by assembling a model ofthe chip combining all of the bus block models. The chip model is thenverified by simulating it with the chip test bench. While the chip testbench has previously been verified on cycle approximate models, thisbehavioral block model of the chip has some cycle accurate operationsand so some refinement of the chip test bench will be required to getthe block model to pass. In some cases, errors may result due tomiss-matches in the block functional model and the bus logic, at whichtime the model may be modified to correct the errors. Once the chip testbench successfully executes on this chip model, the individual bus blockmodels may be sent to the block designers for detailed implementation.

[0719] At step 8612 in FIG. 14, block test benches are extracted. Oncethe chip test bench executes successfully on the chip level bus blockmodel 8710, as illustrated in FIG. 71, probes can be set on theinterfaces of the individual blocks and block test benches can beextracted from chip test bench 8712 as it executes on the model. Theseblock test benches are sent to the block designers for validation of theblocks as they progress through implementation.

[0720] Proceeding next to the logical verification flow illustrated inFIG. 15, the objective of the logical verification tasks is to ensurethat each of the blocks is functionally correct as it progresses throughthe implementation phases of the design (from RTL to pre-layout netliststo post-layout netlists). Also tested is whether the assembled chipcontinues to provide the required functionality.

[0721] Verification may be done either dynamically through functionalsimulation or statically using formal verification tools that performequivalency checks. Dynamic verification requires simulation tools thatare required and described elsewhere in the BBD methodology flow of thepresent invent-ion. Dynamic verification also utilizes vector sets usedelsewhere and so aids in the migration of the test suite from cycleapproximate to cycle accurate in nature. Static verification requiresthe inclusion of new tools. However, static verification will typicallyrun faster than simulation and provides a “complete” equivalency check,in contrast to simulation, which only proves equivalency to the extentthat the test bench exercises the design functionality.

[0722] Next, individual RTL block models are verified at step 8710,wherein RTL simulation models created by the block designers areverified against the chip test bench. This can be done by swapping theblock RTL model with the corresponding behavioral model in the chiplevel behavioral model and performing a mixed mode simulation of thechip using the full chip test bench. In the alternative, the individualblock RTL model can be simulated with the extracted block test bench. Ineither case, miss-matches can be expected due to the transition from acycle approximate model to a cycle accurate model. These miss-matcheswill be resolved by modifying the test bench. If miss-matches aretriggered by missing or incorrect functionality, then the RTL model mustbe modified to correct the errors.

[0723] At step 8712, RTL block models are verified at the chip level.The RTL simulation models for each of the blocks are combined to createa chip level RTL model. This model is verified by simulating with thechip test bench. Again, some errors may be present due to the transitionfrom a cycle approximate model to a cycle accurate model. These errorswill be resolved by modifying the chip test bench. Any functional errorswill have to be resolved by modifying one or more of the block level RTLmodels.

[0724] At step 8714, individual pre-layout block netlists are verified.The post synthesis netlist simulation models for each block are againstthe RTL model for that block.

[0725] At step 8716, dynamic and static chip level pre-layout blocknetlists are verified. Dynamic verification can either be done byswapping the block level post synthesis netlist with the correspondingbehavioral model in the chip level behavioral model and performing amixed mode simulation of the chip using the full chip test bench. In thealternative, the individual block level post synthesis netlist can besimulated with the block test bench. In either case, miss-matches canagain be expected due to the transition from a cycle accurate model to amodel with intra-cycle timing. These miss-matches will be resolved bymodifying the timing strobes within the test bench. Static verificationis performed by running the equivalency checking tools on the postsynthesis netlist and the RTL model for each block. Miss-matches will beresolved by modifying the post synthesis netlist to match the RTL model.

[0726] The post synthesis netlists for each of the blocks are thencombined to create a chip post synthesis netlist. This chip levelnetlist is verified either through simulation or statically throughformal equivalency checking tools. Dynamic verification is accomplishedby simulating the chip post synthesis netlist with the chip test bench.Static chip level pre-layout verification is performed by running theequivalency checking tools on the chip post synthesis netlist and thechip RTL model for each block. Miss-matches will be resolved bymodifying the post synthesis netlist to match the RTL model.

[0727] At step 8718, individual post-layout block netlists are verified.This step is a repeat of step 8714, but with the post-layout netlistsubstituted for the pre-layout netlist. The only difference, at thenetlist level, between these two models should be the modification ofbuffers and drive strengths to achieve the timing goals of the laid-outdesign. Any errors encountered should be limited to the incorrectaddition or deletion of buffers. The timing of the block test bench mayhave to be modified if the post-layout timing changes has moved signalswith respect to the timing strobes.

[0728] This verification may be done either statically or dynamically.Dynamic verification can be done by swapping the block level post layoutnetlist with the corresponding block RTL model in the chip level RTLmodel and performing a mixed mode simulation of the chip using the fullchip test bench. Alternatively, the individual block level post layoutnetlist can be simulated with the block test bench. Static verificationis performed by running the equivalency checking tools on the postlayout netlist and the RTL model for each block. Miss-matches will beresolved by modifying the post synthesis netlist to match the RTL model.

[0729] Verification of the chip level post-layout netlist isaccomplished at step 8720, a repeat of step 8716 but with thepost-layout chip level netlist substituted for the pre-layout netlist.The only difference, at the netlist level, between these two modelsshould be the modification of buffers and drive strengths to achieve thetiming goals of the laid-out design. Any errors encountered should belimited to the incorrect addition or deletion of buffers. Dynamicverification is accomplished by simulating the chip post layout netlistwith the chip test bench. Static verification is performed by runningthe equivalency checking tools on the chip post layout netlist and thechip RTL model. Miss-matches will be resolved by modifying the postlayout netlist to match the RTL model.

[0730] Finally, physical verification is accomplished as illustrated inFIGS. 72 and 73, wherein both block and chip tape out are verified inthe manner understood by one skilled in the art to which the presentinvention pertains. The objective of the physical verification tasks isto verify that the GDSII files created through the block design and chipassembly phases of the design are functionally correct and free of anyviolations of the design rules for the target technology.

[0731] The GDSII for each of the blocks, created by the block designprocess, are verified by running DRCs for the target technology. Anyerrors and warnings are fed back to the block designer for resolution.LVS is also run between the block GDSII file and the post layout netlistfor that block. Any errors or warnings are fed back to the blockdesigner for resolution.

[0732] The GDSII for the complete chip, created by the chip assemblyprocess, is verified by running DRCs for the target technology. Anyerrors and warnings are sent back to the chip assembly designer forresolution. LVS is also run between the chip GDSII file and the postlayout netlist for the chip. Any errors or warnings are fed back to thechip assembly designer for resolution.

[0733] While the invention has been illustrated and described in detailin the drawing and foregoing description, it should be understood thatthe invention may be implemented through alternative embodiments withinthe spirit of the present invention. Thus, the scope of the invention isnot intended to be limited to the illustration and description in thisspecification, but is to be defined by the appended claims.

What is claimed is:
 1. A method for designing a circuit system, themethod being executed by a designer, the method comprising the steps of:(a) selecting a plurality of pre-designed circuit blocks to be used todesign the circuit system; (b) collecting designer's data (includingexperience data, estimation data, and/or implementation data) regardingthe pre-designed circuit blocks, the designer's data being adaptable toa processing method; (c) accepting or rejecting a design of the circuitsystem in a manner based on the designer's data and acceptable degree ofrisk; (d) upon acceptance, forming block specifications containingcriteria and modified constraints for each of the circuit blocks (FEA);(e) upon acceptance, forming block specifications for deploying thecircuit blocks on a floor plan of a chip, in compliance with thecriteria and modified constraints without changing the selected circuitblock and the processing method.
 2. The method of claim 1 , wherein thespecification includes bus identification information.
 3. The method ofclaim 1 , wherein the specification includes test strategies.
 4. Themethod of claim 1 , further comprising the step of: (f) upon acceptance,deploying the circuit blocks on the floor plan of the chip by addingstandard and system specific interface for the circuit blocks.
 5. Themethod of claim 4 , further comprising the step of: (g) forming gluecircuits for interconnecting the circuit blocks.
 6. The method of claim1 , further comprising the step of: (f) forming a top-level plan forfabricating the selected circuit blocks into the chip based on thecircuit specifications.
 7. The method of claim 5 , further comprisingthe step of: (h) verifying the proper execution of each of steps (c),(d), (e), (f), and (g), before completing the process.
 8. A method fordesigning a circuit system, the method being executed by a one or moredesigner, the method comprising the steps of: (a) selecting a pluralityof pre-designed circuit blocks to be used to design the circuit system;(b) collecting data reflecting the experience of the designer regardingthe pre-designed and yet to be designed circuit blocks, the designer'sexperience being adaptable to a processing method; (c) accepting orrejecting a design of the circuit system in a manner based on thedesigner's experience data and acceptable degree of risk; (d) uponacceptance, forming block specifications containing criteria andmodified constraints for each of the circuit blocks; and (e) uponacceptance, creating forming block specifications and glue logic forclocks, power, and bus communication to for deploying the circuit blockson a floor plan of a chip, in compliance with the criteria and modifiedconstraints meet the design objectives without changing the selectedcircuit block and the processing method.
 9. The method of claim 8 ,further comprising the step of: (f) upon acceptance, forming blockspecifications for deploying the circuit blocks on a floor plan of achip, in compliance with the criteria and modified constraints withoutchanging the selected circuit block and the processing method.
 10. Themethod of claim 9 , the step (f) further comprising forming virtualcircuit specifications for each of the circuit blocks, to deploy thecircuit blocks on the floor plan of the chip.
 11. The method of claim 8, the designer's data experience including at least one member of thegroup consisting of: field of use, simulation, and partial or fullimplementation of at least one of the pre-designed blocks.
 12. Themethod of claim 9 , further comprising the step of (g) forming gluelogic for interconnecting the circuit blocks.
 13. The method of claim 9, further comprising the step of (g) forming collar interfaces forinterconnecting the circuit blocks.
 14. The method of claim 9 , the step(f) further comprising: upon acceptance, forming a top-level plan forfabricating the selected circuit blocks into the chip based on thevirtual circuit specifications.
 15. The method of claim 9 , furthercomprising the step of: verifying the proper execution of each of steps(c), (d), (e), and (f) before completing the process.
 16. The method ofclaim 14 , further comprising the step of: generating and verifying theresulting physical layout, mask and test data necessary to fabricatesaid chip.
 17. A method for expanding an existing methodology forassessing feasibility of a circuit design based on a predetermined typeof parameter, the method comprising the steps of: (a) selecting aplurality of circuit blocks to be used in the circuit design; (b)receiving the predetermined type of parameter for the circuit blocks;(c) assessing a first feasibility using the existing methodology basedon the predetermined type of parameter, the first feasibility includinga first risk indicator and first time/cost indicator; (d) receiving atleast a second type of parameter that has not been used in the existingmethodology; (e) processing the second type of parameter to accommodatethe existing methodology; and (f) assessing a second feasibility usingthe existing methodology based on the predetermined type of parameterand the second type of parameter, the second feasibility including asecond risk indicator, and a second time/cost indicator, wherein thesecond risk indicator has not been substantially increased compared withthe first risk factor due to the use of the existing methodology, andthe second time/cost factor has been increased compared with the firsttime/cost factor due to the impact of the second type of parameter. 18.The method of claim 17 , wherein the predetermined type of parameter isfield of use data, and the second type of parameter is either estimationdata or implementation data.
 19. A method for expanding an existingmethodology for assessing feasibility of a circuit design based on apredetermined type of parameter, the method comprising the steps of: (a)selecting a plurality of circuit blocks to be used in the circuitdesign; (b) receiving the predetermined type of parameter for thecircuit blocks; (c) assessing a first feasibility using the existingmethodology based on the predetermined type of parameter, the firstfeasibility including a first risk indicator and first time/costindicator; (d) receiving at least a second type of parameter that hasnot been used in the existing methodology; (e) changing the existingmethodology to accommodate the second type of parameter; and (f)assessing a second feasibility using the changed methodology based onthe predetermined type of parameter and the second type of parameter,the second feasibility including a second risk indicator, and a secondtime/cost indicator, wherein the second risk indicator has beenincreased compared with the first risk factor due to the change of theexisting methodology, and the second time/cost factor has not beensubstantially increased compared with the first time/cost factor due tothe change of the existing methodology.
 20. The method of claim 19 ,wherein the predetermined type of parameter is field of use data, andthe second type of parameter is either estimation data or implementationdata.
 21. A method for expanding an existing methodology for assessingfeasibility of a circuit design based upon a predetermined set of designcharacteristics, the method comprising the steps of: (a) determining tobe the field of use a set of design characteristics for which designrisk is known and acceptably small; (b) selecting a plurality of circuitblocks to be used in the circuit design; (c) receiving predetermineddesign characteristics for the circuit blocks; (d) assessing a firstfeasibility using the existing methodology based upon the field of usecharacteristics, the first feasibility including a first risk indicatorand first time/cost indicator; (e) receiving at least a second designcharacteristic which has not been used in the existing methodology; (f)processing the second design characteristic to accommodate the existingmethodology; and (g) assessing a second feasibility using the existingmethodology based on the field of use characteristics and the seconddesign characteristic, the second feasibility including a second riskindicator, and a second time/cost indicator, wherein the second riskindicator has not been substantially increased compared with the firstrisk factor due to the use of the existing methodology, and the secondtime/cost factor has been increased compared with the first time/costfactor due to the impact of the second design characteristic.
 22. Themethod of claim 21 , where in the predetermined design characteristicsare within the definition of the field of use data, and the error-riskassociated with correct prediction of the second type of designcharacteristic being known from either estimation data or implementationdata.
 23. A method for expanding an existing methodology for assessingfeasibility of a circuit design based upon a predetermined set of designcharacteristics, the method comprising of: (a) determining to be thefield of use a set of design characteristics for which design risk isknown and small; (b) selecting a plurality of circuit blocks to be usedin the circuit design; (c) receiving predetermined designcharacteristics for the circuit blocks; (d) assessing a firstfeasibility using the existing methodology based upon the field of usecharacteristics, the first feasibility including a first risk indicatorand first time/cost indicator; (e) receiving at least a second designcharacteristic which has not been used in the existing methodology; (f)changing the existing methodology to accommodate the second type ofdesign characteristic; (g) assessing the second feasibility using thechanged methodology based on the field of use design characteristics andthe second type of design characteristic, the second feasibilityincluding a second risk indicator, and a second time/cost indicator,wherein the second risk indicator has been increased compared with thefirst risk factor due to the change of the existing methodology, and thesecond time/cost factor has not been substantially increased comparedwith the first time/cost factor due to the change of the existingmethodology.
 24. The-method of claim 23 , where in the predetermineddesign characteristics are within the definition of the field of usedata, and the error-risk associated with correct prediction of thesecond type of design characteristic being known from either estimationdata or implementation data.
 25. A method for performing a feasibilityassessment for a circuit design, comprising the steps of: (a) receivingrequirements and constraints for the circuit design; (b) selecting aplurality of pre-designed circuit blocks to be used in the circuitdesign; (c) collecting field of experience data for the circuit blocks;(d) forming a first level decision rule using the field of experiencedata for the circuit blocks, the first level decision rule including anacceptance region, a rejecting region, and an uncertain region; (e)making a first level predication using the requirements and constraintsbased on the first level decision rule; (f) accepting the circuit designif the first level predication is within the acceptance region of thefirst level decision rule, and rejecting the circuit design if the firstlevel predication is within the rejecting region of the first leveldecision rule; and (g) forming a second level decision rule for making asecond level predication for the circuit design, if the first levelprediction is within the uncertain region of the first level decisionrule.
 26. The method of claim 25 , further comprising the steps of: (h)collecting estimation data for the circuit blocks, wherein the secondlevel decision rule in (g) is formed using the estimation data, thesecond level decision rule including an acceptance region, a rejectingregion, and an uncertain region; (i) making the second level predicationusing the requirements and constraints based on the second leveldecision rule; (j) accepting the circuit design if the second levelprediction is within the acceptance region of the second level decisionrule, and rejecting the circuit design if the second level predicationis within the rejecting region of the second level decision rule; and(k) forming a third level decision rule for making a third levelpredication for the circuit design, if the second level prediction iswithin the uncertain region of the second level decision rule.
 27. Themethod of claim 26 , further comprising the steps of: (L) collectingimplementation data for the circuit blocks, wherein the third leveldecision rule in (k) is formed using the implementation data, the thirdlevel decision rule including an acceptance region, a rejecting region,and an uncertain region; (m) making the third level prediction using therequirements and constraints based on the third level decision rule; (n)accepting the circuit design if the third level prediction is within theacceptance region of the third level decision rule, and rejecting thecircuit design if the third level predication is within the rejectingregion of the third level decision rule.
 28. The method of claim 27 ,wherein: the estimation data has a higher cost of collection and ahigher accuracy than the field of experience data; and theimplementation data has a higher cost of collection and a higheraccuracy than the estimation data.
 29. A method for refining a firstdecision rule for a circuit design, comprising the steps of: (a)receiving requirements and constraints of a circuit design; (b)selecting a plurality of pre-designed circuit blocks to be used in thedesign; (c) identifying at least one of the circuit blocks as a criticalcircuit block and the rest of the circuit blocks as non-critical circuitblocks; (d) collecting field of experience data for the non-criticalcircuit blocks, and collecting estimation data and/or implementationdata for the critical circuit block; and (e) forming a refined firstdecision rule by combining the field of experience data with theestimation data or implementation data.
 30. The method of claim 29 , thedecision rule including an acceptance region, a rejecting region, and anuncertain region, the method further comprising the steps of: (f) makinga prediction using the requirements and constraints based on the refineddecision rule in (e); and (g) accepting the circuit design if thepredication is within the acceptance region, and rejecting the circuitdesign if the predication is within the rejecting region.
 31. The methodof claim 30 , wherein: the estimation data has a higher cost ofcollection and a higher accuracy than the field experience data; and theimplementation data has a higher cost of collection and a higheraccuracy than the estimation data.
 32. A method for forming a seconddecision rule for a circuit design, comprising the steps of: (a)receiving requirements and constraints of the circuit design; (b)selecting a plurality of pre-designed circuit blocks; (c) identifying atleast one of the circuit blocks as a critical block and the rest of thecircuit blocks as non-critical circuit blocks; (d) collecting estimationdata for the non-critical circuit blocks, and collecting implementationdata for the critical circuit block; and (e) forming a refined seconddecision rule by using the estimation data and the implementation data.33. The method of claim 32 , the decision rule including an acceptanceregion, a rejecting region, and an uncertain region, the method furthercomprising the steps of: (f) making a predication using the requirementsand constraints based on the refined decision rule in (e); and (g)accepting the circuit design if the prediction is within the acceptanceregion, and rejecting the circuit design if the predication is withinthe rejecting region.
 34. The method of claim 33 , wherein: theimplementation data has a higher cost of collection and a higheraccuracy than the estimation data.
 35. A method for organizingexperience data of a designer regarding a plurality of pre-designedcircuit blocks to be used to design a circuit system, wherein the methodis executed by the designer and the experience data is used to perform afeasibility assessment for the circuit system design, the methodcomprising the steps of: (a) defining a set of parameters by whichexperience data can be measured; (b) identifying experience data of thedesigner regarding the circuit blocks; (c) classifying the identifieddesigner's experience data into a plurality of classes, wherein theexperience data classes correspond to the circuit blocks; (d) using thedesigner's experience data to form a decision rule, the decision ruleincluding an acceptance region, a rejecting region, and an uncertainregion; and (e) making a prediction using the requirements andconstraints based on the decision rule.
 36. The method of claim 35 ,further comprising the step of: (f) accepting the circuit system designif the estimation is within the acceptance region of the decision rule,and rejecting the circuit system design if the estimation is within therejecting region of the decision rule.
 37. The method of claim 35 ,further comprising the step of: (f) refining the classes of theexperience data to minimize feasibility assessment error.
 38. The methodof claim 35 , further comprising the step of: (f) certifying theexperience data.
 39. The method of claim 35 , wherein the identifiedexperience data includes at least one of predicted experience data orcollated experience data.
 40. The method of claim 35 , furthercomprising the step of: (f) building a model upon the identifieddesigner's experience data to predict similar parameters of a similardesign.
 41. For execution in an integrated circuit device design scheme,wherein a device design comprises a plurality of pre-existing designblocks, a method of increasing glue logic distribution efficiency, themethod comprising the steps of: copying a selected glue logic element,thereby creating a duplicate element set including said selected elementand its copy; distributing said duplicate element set to the pluralityof design blocks.
 42. For execution in an integrated circuit devicedesign scheme, wherein a device design comprises a plurality ofpre-existing design blocks, a method of distributing a plurality of gluelogic elements among the design blocks, the method comprising the stepsof: if a first glue logic element includes an output net driving aplurality of loads, splitting the first element into a plurality ofderivative glue logic elements; and distributing said derivativeelements to the plurality of design blocks.
 43. The method of claim 42 ,wherein each derivative element includes only a single output load. 44.The method of claim 42 , wherein if a first glue logic element includesa plurality of inputs, the split element is the first element.
 45. Themethod of claim 42 , wherein a derivative element includes onlytwo-inputs.
 46. For execution in an integrated circuit device designscheme, wherein a device design comprises a plurality of pre-existingdesign blocks, a method of distributing a plurality of glue logicelements among the design blocks, the method comprising the steps of:analyzing the plurality of elements for a selected quality; merging aselected glue logic element into a selected block in a manner based uponthe analysis.
 47. The method of claim 46 , wherein the selected block isselected in a manner based upon its functional affinity to the selectedelement.
 48. The method of claim 47 , wherein said functional affinitycomprises whether the merger would reduce the number of physical I/Oelements required for the proper function of said circuit device design.49. The method of claim 46 , wherein if two or more design blocks areequal candidates for the merger, the block having the lowest pin densityis chosen.
 50. The method of claim 47 , wherein said functional affinitycomprises whether a selected element and a selected block together haveimproved chip level timing characteristics.
 51. For execution in anintegrated circuit device design scheme, wherein a device designcomprises a plurality of pre-existing design blocks, a method ofdistributing glue logic, the method comprising the steps of: identifyinga plurality of elements that can be neither copied and distributed amongthe design blocks or merged with the design blocks; clustering theidentified plurality of elements.
 52. The method of claim 51 , whereineach of the clustered elements includes multiple loads on input nets andmultiple loads on output nets.
 53. The method of claim 51 , wherein theplurality of elements include inputs having similar function.
 54. Forexecution in an integrated circuit device design scheme, wherein adevice design comprises a plurality of pre-existing design blocks, amethod of distributing glue logic among the design blocks, the methodcomprising the steps of: identifying a first feature of a first gluelogic element; identifying a second glue logic element having a secondfeature making the second glue logic element compatible with the firstglue logic element; merging said first glue logic element with theidentified second glue logic element.
 55. The method of claim 54 whereinsaid first feature comprises the number of pins required by said firstglue logic element.
 56. The method of claim 54 wherein said firstfeature comprises the input structure of said first glue logic element.57. The method of claim 54 wherein said first feature comprises theoutput structure of said first glue logic element.
 58. The method ofclaim 54 wherein the second glue logic element is a design block.
 59. Amethod for converting a specific interface of a circuit block, themethod comprising the steps of: (a) defining a standard interface; and(b) connecting a collar interface to the circuit block, the interfacehaving a first portion connectable to the circuit block, a secondportion in compliance with the standard interface, and a third portionfor converting the specific interface into the standard interface. 60.The method of claim 59 , wherein the collar interface can be in hard,soft, or firm format.
 61. The method of claim 59 , wherein the circuitblock is a memory, a processor, a random logic, or an analog/mixedsignal.
 62. The method of claim 59 , wherein the collar interfaceincludes multiple layers, including a block-specific standard layer anda system-specific layer.
 63. A method for connecting a first circuitblock and a second circuit block, the first circuit block having a firstspecific interface and the second circuit block having a second specificinterface, the method comprising the steps of: (a) defining a standardinterface for connecting the first and second circuit blocks; (b)connecting a first collar interface to the first circuit block, thefirst interface having a first portion connectable to the first circuitblock, a second portion in compliance with the standard interface, and athird portion for converting the first specific interface into thestandard interface; (c) connecting a second collar interface to thesecond circuit block, the second collar interface having a first portionbeing able to be connected to the second circuit block, a second portionin compliance with the standard interface, and a third portion forconverting the second specific interface into the standard interface;and (d) connecting the first and second circuit blocks using thestandard interface.
 64. The method of claim 63 , wherein the first andsecond collar interfaces can be in hard, soft, or firm format.
 65. Themethod of claim 63 , wherein the first and second circuit block is amemory, a processor, a random logic, or an analog/mixed signal.
 66. Themethod of claim 63 , wherein the first and second collar interfacesinclude multiple layers, including a block-specific standard layer and asystem-specific layer.
 67. A collar interface for converting a specificinterface of a circuit block into a standard interface, the collarinterface comprising: (a) a first portion containing componentsconnectable to the specific interface of the circuit block; (b) a secondportion in compliance with the standard interface; and (c) a thirdportion for converting the specific interface into the standardinterface.
 68. The collar interface of claim 67 , wherein the apparatuscan be in hard, soft, or firm format.
 69. The collar interface of claim67 , wherein the circuit block is a memory, a processor, a random logic,or an analog/mixed signal.
 70. The collar interface of claim 67 ,wherein the collar includes multiple layers, including a block-specificstandard layer and a system-specific layer.
 71. An interface system forconnecting a first circuit block and a second circuit block through astandard interface, the first circuit block having a first specificinterface and the second circuit block having a second specificinterface, the interface system comprising: (a) a first collar interfaceconnected to the first circuit block, the first collar interfaceincluding (1) a first portion containing components connectable to thespecific interface of the first circuit block, (2) a second portion incompliance with the standard interface, and (3) a third portioncontaining components for converting the first specific interface intothe standard interface; and (b) a second collar interface connected tothe second circuit block, the second collar interface including (10) afirst portion containing components connectable to the specificinterface of the second circuit block, (2) a second portion incompliance with the standard interface, and (3) a third portioncontaining components for converting the second specific interface intothe standard interface.
 72. The interface system of claim 71 , whereinthe first and second collar interfaces can be in hard, soft, or firmformat.
 73. The interface system of claim 71 , wherein the first andsecond circuit block is a memory, a processor, a random logic, or ananalog/mixed signal.
 74. The interface system of claim 71 , wherein thefirst and second collar interfaces include multiple layers, including ablock-specific standard layer and a system-specific layer.
 75. In acircuit design method, wherein a circuit under design comprises aplurality of pre-existing design blocks, a method of selecting a circuitbus, the method comprising the steps of: observing data transactionalbehavior between the plurality of design blocks; deriving from theobserved transactional behavior a plurality of bus criteria; selecting abus structure from a library of available bus design blocks in a mannerbased upon said plurality of bus criteria; integrating said selected busstructure into said circuit.
 76. The method of claim 75 , wherein saidplurality of bus criteria comprise at least one member of the groupconsisting of bus size, bus bandwidth, bus performance level, and signallatency.
 77. The method of claim 75 further comprising, before selectinga bus, clustering the plurality of design blocks according to aplurality of communication requirements between the blocks, therebyforming a plurality of block clusters.
 78. The method of claim 77 ,wherein assigned to each formed cluster is a bus selection criteriacomprising at least one member of the group consisting of bus size, busbandwidth, bus performance level, and signal latency.
 79. The method ofclaim 75 , wherein the deriving step comprises deriving requirements forcommunications between at least one of the blocks and an I/O structurewithin the circuit.
 80. The method of claim 75 , further comprisingmapping the selected bus structure into the circuit by modifying its businterface logic.
 81. The method of claim 75 , wherein said deriving stepcomprises:creating a data transfer matrix, including a plurality of datatransfer count entries; and organizing the data transfer matrix bymoving the largest of the counts toward a central axis in the matrix;82. The method of claim 81 , wherein said deriving step furthercomprises: weighting the count entries according to a selected weightingcriteria.
 83. The method of claim 77 , wherein said deriving stepcomprises creating a cluster value matrix, including a plurality of datarepresenting distribution of data flow within the bus to be selected;optimizing data flow within the bus to be selected by selectivelyreorganizing said distribution data.
 84. The method of claim 75 ,wherein the step of observing data transactional behavior is performedon a behavioral model.
 85. The method of claim 84 , wherein thebehavioral model includes a plurality of design blocks and an I/Ostructure.
 86. The method of claim 84 , wherein the behavioral model ismodified to collect transaction data.
 87. In a block based designmethodology for realizing a circuit design, the design comprising aplurality of pre-existing design blocks, a method of designing a deviceembodying the design and enabling testing of the device aftermanufacture, the method comprising the steps of: establishing a testdevelopment framework; developing, in compliance with the framework, aplurality of test blocks for testing the design blocks; mapping theplurality of test blocks to develop, in compliance with the framework, atest for the circuit design.
 88. The method of claim 87 , wherein theestablishing step comprises identifying the plurality of pre-existingdesign blocks according to a set of qualifiers, said qualifierscomprising at least one entry from the group consisting of a test model,a test method, a test data, and a test interface.
 89. The method ofclaim 88 , wherein the set of qualifiers comprises an abstraction of thedesign blocks, enabling top-down test planning.
 90. The method of claim87 , wherein the framework comprises a test budget for each of theblocks.
 91. The method of claim 87 , further comprising enablingconcurrent testing on more than one of the blocks.
 92. The method ofclaim 91 , wherein said enabling step comprises expanding a device-leveltest interface.
 93. The method of claim 91 , wherein said enabling stepcomprises manipulating a tester timeset to minimize tester setup timebetween test blocks.
 94. The method of claim 87 , further comprisingpackaging the framework and a block test as a test-ready design blockfor test re-usability.
 95. A method of designing an integrated circuitdevice for post-manufacturing testability, the circuit comprising aplurality of pre-existing design blocks, the method comprising the stepsof: abstracting each of the pre-existing blocks to establish a circuittest development framework; formulating a design scheme, including aplurality of tests, for the device while maintaining a predictableestimation of the overall testability of the circuit design.
 96. Themethod of claim 95 , wherein the circuit testing framework is optimizedfor a plurality of test objectives.
 97. The method of claim 95 , whereinthe circuit testing framework will be rejected if a risk level ofreaching a pre-determined block testability level is greater than anacceptable level.
 98. The method of claim 95 , wherein the frameworkcomprises test cost budgeting criteria.
 99. The method of claim 98 ,further comprising the execution of test efficacy exchanges by adding atest to the design scheme.
 100. The method of claim 98 , furthercomprising the execution of test efficacy exchanges by removing a testfrom the design scheme.
 101. The method of claim 95 , further comprisingrefining the design scheme within designated tolerances.
 102. The methodof claim 95 , further comprising enabling concurrent test development aspart of the design scheme, by allowing each block to be tested with aselected suitable test method.
 103. The method of claim 95 , wherein thedesign scheme includes a test interface and the interface is compatiblewith a plurality of dissimilar test protocols.
 104. The method of claim95 , further comprising simplifying a test scheduling portion of thedesign scheme by concurrently executing more than one block test. 105.The method of claim 95 , further comprising duplicating test vectorsamong design blocks, thereby reducing the elapsed time between testblocks with the design scheme.
 106. The method of claim 95 , wherein aplurality of similar test blocks are executed consecutively, therebyreducing elapsed test time.
 107. The method of claim 95 , furthercomprising using designer feedback to update the design scheme foradaptation to a plurality of circuit designs.
 108. A method of verifyingthe proper function of a circuit design, the design comprising aplurality of pre-existing design blocks, the method comprising the stepsof: obtaining a circuit design model and a circuit test bench;partitioning the circuit design model into a plurality of block models;creating a bus model interconnecting the plurality of block models;creating a plurality of test benches for verifying the plurality ofblock models and bus model; using the test benches to verify thefunction of the plurality of block models and the bus model.
 109. Themethod of claim 108 , wherein the circuit design model includes a toplevel.
 110. The method of claim 108 , wherein the bus model comprisesglue logic circuitry from the block models.
 111. The method of claim 108, wherein verifying the function of a block model comprises registertransfer language verification/
 112. The method of claim 108 , whereinverifying the function of a block model comprises pre-layout netlistverification.
 113. The method of claim 108 , wherein verifying thefunction of a block model comprises post-layout netlist verification.114. The method of claim 108 , wherein after attempting to verify theplurality of block models, the plurality of block models are modifiedfor cycle accuracy.
 115. The method of claim 108 , further comprisingthe steps of: developing a test bench for the circuit design; andattempting to verify the function of the circuit design.
 116. The methodof claim 115 , wherein verifying the function of the circuit designcomprises register transfer language verification.
 117. The method ofclaim 115 , wherein verifying the function of the circuit designcomprises pre-layout netlist verification.
 118. The method of claim 115, wherein verifying the function of the circuit design comprisespost-layout netlist verification.
 119. The method of claim 108 , whereinafter attempting to verify the circuit design, the circuit test bench ismodified for cycle accuracy.
 120. A method for evolving an initialbehavioral level test bench with no timing content into a cycle accuratetest bench suitable for functional verification of all timing accurateviews of the design, the method comprising the steps of: determininginvariant output of execution of the design on the test bench; modifyingthe test bench to include clocks; executing the modified test bench on atiming accurate model; and comparing the invariant output of the testbench.
 121. A method of verifying the proper function of a circuitdesign, the design comprising a plurality of pre-existing design blocks,the method comprising the steps of: obtaining a circuit design modelincluding a top level and a plurality of block models; obtaining circuittest bench; creating a bus model interconnecting the plurality of blockmodels; creating a plurality of test benches for verifying the pluralityof block models and bus model; using the test benches to verify thefunction of the plurality of block models and the bus model.
 122. Amethod for evolving an initial behavioral level test bench withouttiming content into a cycle accurate test bench suitable for functionalverification of substantially timing-accurate views of a design, themethod comprising the steps of: determining an invariant output ofexecution of the design on the test bench; modifying the test bench toinclude clocks; executing the modified test bench on a substantiallytiming-accurate model; and comparing the invariant output of thetestbenches.